atom feed17 messages in org.oasis-open.lists.security-servicesRE: [security-services] LDAP Attribut...
FromSent OnAttachments
Greg WhiteheadJan 12, 2006 5:16 pm 
Scott CantorJan 12, 2006 7:21 pm 
Greg WhiteheadJan 12, 2006 8:22 pm 
Reid, IrvingJan 13, 2006 7:15 am 
Scott CantorJan 13, 2006 7:30 am 
Greg WhiteheadJan 16, 2006 8:08 am 
Scott CantorJan 16, 2006 11:30 am 
Greg WhiteheadJan 16, 2006 12:11 pm 
Scott CantorJan 16, 2006 12:16 pm 
Prateek MishraJan 16, 2006 3:14 pm 
RL 'Bob' MorganJan 17, 2006 12:15 am 
RL 'Bob' MorganJan 17, 2006 1:05 am 
RL 'Bob' MorganJan 17, 2006 1:32 am 
Greg WhiteheadJan 17, 2006 6:43 am 
Greg WhiteheadJan 17, 2006 6:45 am 
Scott CantorJan 17, 2006 8:49 am 
Reid, IrvingJan 17, 2006 9:10 am 
Subject:RE: [security-services] LDAP Attribute Profile (saml-profiles-saml2.0)
From:Reid, Irving (irvi@hp.com)
Date:Jan 17, 2006 9:10:16 am
List:org.oasis-open.lists.security-services

Actually, contrary to Bob's comment below, I didn't say that our product includes the ASN.1; I'm not actually sure what we do (Greg? Do you know?). I'd actually prefer to omit the ASN.1 wrapper, which I think is the growing consensus. My previous message was more of an exploration in trying to see the original profile author's point of view.

- irving -

-----Original Message----- From: Whitehead, Greg Sent: January 17, 2006 09:46 To: RL 'Bob' Morgan Cc: OASIS Security Services TC Subject: Re: [security-services] LDAP Attribute Profile (saml-profiles-saml2.0)

On Jan 17, 2006, at 3:33 AM, RL 'Bob' Morgan wrote:

On Mon, 16 Jan 2006, Greg Whitehead wrote:

2) The ONLY clue we have that the AttributeValue is encoded using the X500/LDAP profile is an attribute in the profile namespace (x500:Encoding). Unless we know to look for that attribute, or we search for all attributes that we don't understand and throw up our hands if any are found, there is NO way to know what crazy encoding rules have been applied to the AttributeValue (such as ASN.1 octet string wrappers).

Hmm, the point of the ldapprof:Encoding="LDAP" XML attribute isn't to call out the use of the X.500/LDAP profile as a whole, it's to indicate that, in that profile, the LDAP-specific encoding is being used, rather than any other possible encodings, none of which have been defined yet (but possibilities might include X.500 and RXER some day). If we had decided not to leave the door open for those other encodings, but said this profile is only LDAP forever, there would have been no Encoding XML attribute at all.

Ok, so unlike the Basic profile, where we have a profile-specific NameFormat, with the X.500/LDAP profile we're not flagging the use of the profile in-band (unless you count recognizing particular OIDs as being X.500/LDAP attributes). Instead, a deployment would need to configure each OID that it "knows" to use the X.500/LDAP profile for encoding/decoding.

This works, but it probably deserves some mention in errata.

So I think the point is that by using as a SAML attribute Name an OID that is defined as an X.500/LDAP attribute type, you're using the X.500/LDAP profile, like it or not. So it's like Scott said about LDAP: the format is determined by the attribute name, which should be clear, no?

Right. Of course, I can define my own OIDs and then those would have to be communicated out-of-band to my peers and configured accordingly before they could be processed.

I suppose someone could come along and add a myFormat="Klingon" XML attribute to the AttributeValue element of any SAML Attribute in hopes it would affect the processing. Should SAML attribute profiles have language specifically precluding this? Seems like trying to specify common sense.

Well, my point was that this is how the x500:Encoding="LDAP" XML attribute looked to me... but then I was looking for some way to detect the X.500/LDAP profile in-band. If you say that it can't be detected in-band (for any OID) then that's fine.

- RL "Bob"