On Jan 16, 2006, at 1:30 PM, Scott Cantor wrote:
>> This strikes me as a very poor design pattern. It would be much
>> better to have a well known Format/Encoding attribute on
>> AttributeValue that unambiguously instructs the receiver on how to
>> process the value.
>
> In other words, an OID that corresponds to some LDAP profile
> attribute is
> going to be expressed with the LDAP profile, and ok, there might be
> an XACML
> DataType thing sitting in there also because they're basically
> orthogonal
> profiles.
>
> It's all worthless if I can't tell from the OID that I should
> process it
> with the LDAP profile, which is your point.
Right, I'd be happiest if the NameFormat was urn:oasis:names:tc:SAML:
2.0:profiles:attribute:X500 and that implied OID URNs.
The next best thing would be NameFormat urn:oasis:names:tc:SAML:
2.0:attrname-format:uri, as we have, but clear rules about how values
corresponding to certain OIDs will be encoded.
With what we have, I could go write a new profile that uses
NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:uri and says
that all string values will be ROT-13. Any implementation that knew
that some OID was a string attribute, but that didn't know to do the
ROT-13 decode would be lost. Even if I was generous and required an
attribute rot:Shift="13", to flag values using this profile, your
implementation would have to be prepared to throw up its hands if it
detected any attributes that it didn't recognize (in other words, all
attributes would effectively have to be MUST UNDERSTAND).
>
> -- Scott
>
