com.unboundid.scim2.common.types.Adress is missing "value" and "display" attributes

[wwebers]

Adress is a multi-valued type according to RFC-7643. However, it's missing the both attributes "value" and "display".

That leads to problems when using the client library with SCIM2 conformant servers.

[kqarryzada]

Unless I'm mistaken, I don't see either of those fields for addresses in RFC 7643 section 4.1.2:

addresses
A physical mailing address for this user. Canonical type values
of "work", "home", and "other". This attribute is a complex type
with the following sub-attributes. All sub-attributes are
OPTIONAL.
 
formatted
The full mailing address, formatted for display or use
with a mailing label. This attribute MAY contain newlines.
 
streetAddress
The full street address component, which may
include house number, street name, P.O. box, and multi-line
extended street address information. This attribute MAY
contain newlines.
 
locality
The city or locality component.
 
region
The state or region component.
 
postalCode
The zip code or postal code component.
 
country
The country name component. When specified, the value
MUST be in ISO 3166-1 "alpha-2" code format [ISO3166]; e.g.,
the United States and Sweden are "US" and "SE", respectively.

I'm going to close this, but let me know if you find any indication that these two attributes are expected.

[wwebers]

@kqarryzada I propose to reopen this issue as your reference to RFC 7643 section 4.1.2 is just one part. As stated there address is a multi-valued and complex type. The attributes for multi-valued types are defined in RFC 7643 section 2.4.
All other classes for multi-valued in this package respect the standard, but addresses. Problem is that the absence of display and value leads to problems during serialization/deserialization at servers expecting such attributes according section 2.4 of the RFC.

[kqarryzada]

Certainly. I haven't gotten a chance to look into this much further, but wanted to re-open it right away. I'll let you know if I have further questions.

[kqarryzada]

@wwebers, this is tricky. I've taken a look at section 2.4, and I notice that it says:

If not otherwise defined, the default set of sub-attributes for a multi-valued attribute is as follows:
type
primary
display
value
$ref

In section 4.1.2, addresses is the only attribute that lists a set of its own sub-attributes. It also says:

This attribute is a complex type with the following sub-attributes.

So it doesn't imply that the listed sub-attributes are in addition to the default set of attributes. To me, these two sections suggest that the default set of attributes do not apply to addresses. However, the section does mention that type is a valid field, though, which makes this confusing. The SCIM SDK does support this explicitly mentioned field, at least.

What SCIM servers/services have you seen that accept addresses.value and addresses.display as valid attributes?

[wwebers]

Sorry for the late answer. Anyway, when I started this issue we tried out PingIdentity as well as an own solution realized on the IdentityServer framwork, which worked fine for another SCIM framework.
Obviously, the SCIM specification leaves some room for interpretation, which is unfortunate. IMHO, such type of specifications should not leave such a head room.