[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)
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. > > -Greg > > > > > - RL "Bob" > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all > your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr > oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]