Re: [security-services] LDAP Attribute Profile (saml-profiles-saml2.0)

[Greg Whitehead <greg.whitehead@hp.com>]

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
>