[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] LDAP Attribute Profile (saml-profiles-saml2.0)
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]