RE: Integration with Enterprise Directory Services
> > Drummond Reed wrote: > > Yes, Marty Schleiff at Boeing is working on an RFC for how to represent > XRIs > > in an LDAP directory for that very reason -- to establish standard OIDs > for > > this attribute. LDAP already has a URI attribute type, but downcasting > an > > XRI into a URI just to squeeze it into that attribute type loses the > > semantics that the XRI is an abstract identifier for the resource. So > Boeing > > wants to establish OIDs for primary-xri (value of the canonical XRI) and > > alt-xri (value of any other XRI synonym). > > > > Martin Atkins wrote: > > This is perhaps a bit of a tangent, but what are the disadvantages to > representing XRI as a URI? It seems to me that having two completely > orthogonal sorts of identifier rather than having one be a "subset" of > the other just makes things needlessly complex. What makes you consider > XRI to be an "abstract identifier" but a URI not to be? Mart, to clarify: after the transformation defined in the XRI spec, an XRI is a valid URI the same way an IRI, after the transformation defined in the IRI spec (RFC 3987) is a valid URI. Both XRIs and IRIs had good reasons to define syntax that, before the transformation, is not valid URI syntax because both add features not supported in URI syntax. In IRI's case, it was support for internationalized characters. In XRI's case, it was support for structured identifier syntax that is particularly useful for abstract (vs. concrete) identifiers. What makes XRI identifiers abstract is simply that this "branch" of the URI family has been defined explicitly for abtract identifiers (i.e., identifiers which resolve into other concrete identifiers, vs. directly to a resource location), and XRI infrastructure is being deployed for that purpose. The same could be said of URNs: they are the "branch" of the URI tree designed to meet the requirements of persistent identifiers, and URN infrastructure has been deployed for that purpose. That doesn't mean every URN is in fact persistent any more than it means every XRI is abstract, but that's the intent. > The whole thing of just starting with an equals sign is very cute, but > surely that's just a shorthand to avoid writing "xri://" in contexts > where it's unambiguous, much like people routinely write things like > "www.google.com" when an "http:" URI is expected. Yes and no: "Yes" because the XRI specifications are very clear that if you cast an XRI into an IRI or URI (which presumably you would if you wanted it to be recognized as an IRI or URI), then you MUST add the "xri://" prefix. "No" because the XRI TC realized that the pattern of not including scheme name is not just an anomaly -- it represents a very common human usability requirement that is now supported in popular text editors and other computer tools on every platform. However the "www." convention is just that -- a convention for meeting this usability requirement that is not formalized anywhere. By contrast, the XRI TC put human usability explicitly in scope, and felt that defining a clear and unambiguous specification for such prefixes would ultimately lead to a much better user experience across the vast variety of applications and contexts in which abstract identifiers may ultimately be used. It was that requirement that led to the solution of using "the simplest thing that could possible work" -- single-character "global context symbols". Net net: the fact that all absolute XRIs start with a global context symbol not just a coincidence (or "cute" as you put it), but an explicit usability design decision so that XRIs would be as unambiguous as possible in ordinary text WITHOUT the need for a URI-conformant scheme name (which to the vast majority of users is unintuitive and "geeky"). BTW, = is just one of four global context symbols -- the others are @ for organizational identifiers, + for generic identifers, and $ for specified identifiers. (In XRI Syntax 2.0, ! was defined as a both a local and global context symbol, but its use a global context symbol is planned to be deprecated in XRI 3.0.) Hope this helps, =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Integration with Enterprise Directory Services
Drummond Reed wrote: > Yes, Marty Schleiff at Boeing is working on an RFC for how to represent XRIs > in an LDAP directory for that very reason -- to establish standard OIDs for > this attribute. LDAP already has a URI attribute type, but downcasting an > XRI into a URI just to squeeze it into that attribute type loses the > semantics that the XRI is an abstract identifier for the resource. So Boeing > wants to establish OIDs for primary-xri (value of the canonical XRI) and > alt-xri (value of any other XRI synonym). > This is perhaps a bit of a tangent, but what are the disadvantages to representing XRI as a URI? It seems to me that having two completely orthogonal sorts of identifier rather than having one be a "subset" of the other just makes things needlessly complex. What makes you consider XRI to be an "abstract identifier" but a URI not to be? The whole thing of just starting with an equals sign is very cute, but surely that's just a shorthand to avoid writing "xri://" in contexts where it's unambiguous, much like people routinely write things like "www.google.com" when an "http:" URI is expected. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Integration with Enterprise Directory Services
+1. Since the results would apply to both URLs and XRIs, I expect several XRI TC members would be willing to help review such guidelines. =Drummond > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of John Ehn > Sent: Friday, January 25, 2008 3:34 PM > To: McGovern, James F (HTSC, IT) > Cc: > Subject: Re: Integration with Enterprise Directory Services > > James, > > It appears you possess a good amount of knowledge on this topic. > > I believe that if you were to come up with some preliminary > implementation guidelines (and presented them here for review), you > would not be stepping on anyone's toes. > > Thank you, > > John Ehn > > On Jan 25, 2008, at 3:59 PM, "McGovern, James F (HTSC, IT)" > <[EMAIL PROTECTED] > > wrote: > > > Is there merit in also defining other aspects such as how the OP would > > store history in LDAP by defining new ObjectClass? > > > > > > *** > > ** > > This communication, including attachments, is > > for the exclusive use of addressee and may contain proprietary, > > confidential and/or privileged information. If you are not the > > intended > > recipient, any use, copying, disclosure, dissemination or > > distribution is > > strictly prohibited. If you are not the intended recipient, please > > notify > > the sender immediately by return e-mail, delete this communication and > > destroy all copies. > > *** > > ** > > > > ___ > > specs mailing list > > specs@openid.net > > http://openid.net/mailman/listinfo/specs > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Integration with Enterprise Directory Services
James, It appears you possess a good amount of knowledge on this topic. I believe that if you were to come up with some preliminary implementation guidelines (and presented them here for review), you would not be stepping on anyone's toes. Thank you, John Ehn On Jan 25, 2008, at 3:59 PM, "McGovern, James F (HTSC, IT)" <[EMAIL PROTECTED] > wrote: > Is there merit in also defining other aspects such as how the OP would > store history in LDAP by defining new ObjectClass? > > > *** > ** > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the > intended > recipient, any use, copying, disclosure, dissemination or > distribution is > strictly prohibited. If you are not the intended recipient, please > notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > *** > ** > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Integration with Enterprise Directory Services
We should do whatever it takes to make OpenID successful within an enterprise setting and not exclusively focus on consumerish usage scenarios. I would think that folks from Sun and other large ISPs would also leverage directory services. Likewise for those providing OpenID libraries, you software should work in enterprise settings while minimizing configuration regardless of how easy it is. -Original Message- From: Schleiff, Marty [mailto:[EMAIL PROTECTED] Sent: Thursday, January 24, 2008 8:17 PM To: Johannes Ernst; specs@openid.net Cc: McGovern, James F (HTSC, IT); Drummond Reed Subject: RE: Integration with Enterprise Directory Services The process to get an OID issued under the directory OID includes doing an RFC. The old draft (haven't touched it for about a year) can be seen at various URLs. Here's one: http://opends.org/source/xref/trunk/www/public/standards/draft-schleiff- ldap-xri.txt [EMAIL PROTECTED]; CISSP Associate Technical Fellow - Cyber Identity Specialist Information Security - Technical Controls (206) 679-5933 * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Integration with Enterprise Directory Services
Is there a draft available? BTW, why would that be an RFC, as opposed to, say, an OASIS standard (XRI) or an OpenID standard? Because of LDAP? As a "user-centric" technology, I'm not sure that a preferred close relationship to corporate directories -- as opposed to other possible places -- is necessarily the right place for it ... On Jan 24, 2008, at 12:34, Drummond Reed wrote: > Yes, Marty Schleiff at Boeing is working on an RFC for how to > represent XRIs > in an LDAP directory for that very reason -- to establish standard > OIDs for > this attribute. LDAP already has a URI attribute type, but > downcasting an > XRI into a URI just to squeeze it into that attribute type loses the > semantics that the XRI is an abstract identifier for the resource. > So Boeing > wants to establish OIDs for primary-xri (value of the canonical XRI) > and > alt-xri (value of any other XRI synonym). > > OpenID URLs really have the same problem -- yes, they are URLs, but > they are > URLs with the specific property of being OpenID URLs. The LDAP URI > attribute > doesn't have that semantics. > > I don't think Marty's on this list but I'm cc'ing him. > > =Drummond > > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf >> Of McGovern, James F (HTSC, IT) >> Sent: Thursday, January 24, 2008 10:12 AM >> To: Johannes Ernst >> Cc: specs@openid.net >> Subject: RE: Integration with Enterprise Directory Services >> >> Would even take it to ensuring that directories use a common OID >> and not >> just making up their own attribute. Staying equivalent to Cardspace >> is a >> good thing. >> >> -Original Message- >> From: Johannes Ernst [mailto:[EMAIL PROTECTED] >> Sent: Thursday, January 24, 2008 1:00 PM >> To: McGovern, James F (HTSC, IT) >> Cc: specs@openid.net >> Subject: Re: Integration with Enterprise Directory Services >> >> This doesn't necessarily belong into the core protocol specs, as many >> implementations will store OpenIDs in places other than directories. >> >> However, it would make sense to have a common convention for that ... >> perhaps a separate 1-page "standard"? >> >> >> On Jan 24, 2008, at 7:02, McGovern, James F (HTSC, IT) wrote: >> >>> For CardSpace, MS and other providers store it in the SeeAlso >>> attribute. Figured OpenID in the next rev of the spec should talk >>> more >> >>> about implementation details. >>> >>> -Original Message- >>> From: Drummond Reed [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, January 23, 2008 11:57 PM >>> To: McGovern, James F (HTSC, IT); specs@openid.net >>> Subject: RE: Integration with Enterprise Directory Services >>> >>> James, are you asking about the recommended format for saving an >>> OpenID identifier in an LDAP directory? If so, I know Boeing has >>> done >>> some work in that area -- I can check with their directory guru. >>> >>> =Drummond >>> >>>> -Original Message- >>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>>> Behalf Of McGovern, James F (HTSC, IT) >>>> Sent: Wednesday, January 23, 2008 1:47 PM >>>> To: specs@openid.net >>>> Subject: Integration with Enterprise Directory Services >>>> >>>> What is the standard recommendation for how identifiers get >>>> stored in >> >>>> enterprise directory services (e.g. LDAP)? >>>> >>>> > > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Integration with Enterprise Directory Services
Would you be willing to propose something? On Jan 24, 2008, at 10:11, McGovern, James F (HTSC, IT) wrote: > Would even take it to ensuring that directories use a common OID and > not > just making up their own attribute. Staying equivalent to Cardspace > is a > good thing. > > -Original Message- > From: Johannes Ernst [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 24, 2008 1:00 PM > To: McGovern, James F (HTSC, IT) > Cc: specs@openid.net > Subject: Re: Integration with Enterprise Directory Services > > This doesn't necessarily belong into the core protocol specs, as many > implementations will store OpenIDs in places other than directories. > > However, it would make sense to have a common convention for that ... > perhaps a separate 1-page "standard"? > > > On Jan 24, 2008, at 7:02, McGovern, James F (HTSC, IT) wrote: > >> For CardSpace, MS and other providers store it in the SeeAlso >> attribute. Figured OpenID in the next rev of the spec should talk >> more > >> about implementation details. >> >> -Original Message- >> From: Drummond Reed [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, January 23, 2008 11:57 PM >> To: McGovern, James F (HTSC, IT); specs@openid.net >> Subject: RE: Integration with Enterprise Directory Services >> >> James, are you asking about the recommended format for saving an >> OpenID identifier in an LDAP directory? If so, I know Boeing has done >> some work in that area -- I can check with their directory guru. >> >> =Drummond >> >>> -Original Message- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>> Behalf Of McGovern, James F (HTSC, IT) >>> Sent: Wednesday, January 23, 2008 1:47 PM >>> To: specs@openid.net >>> Subject: Integration with Enterprise Directory Services >>> >>> What is the standard recommendation for how identifiers get stored >>> in > >>> enterprise directory services (e.g. LDAP)? >>> >>> >>> >>> * >>> * >>> *** This communication, including attachments, is for the exclusive >>> use of addressee and may contain proprietary, confidential and/or >>> privileged information. If you are not the intended recipient, any >>> use, copying, disclosure, dissemination or distribution is strictly >>> prohibited. If you are not the intended recipient, please notify >>> the > >>> sender immediately by return e-mail, delete this communication and >>> destroy all copies. >>> * >>> * >>> *** >>> >>> ___ >>> specs mailing list >>> specs@openid.net >>> http://openid.net/mailman/listinfo/specs >> >> >> >> ** >> *** This communication, including attachments, is for the exclusive >> use of addressee and may contain proprietary, confidential and/or >> privileged information. If you are not the intended recipient, any >> use, copying, disclosure, dissemination or distribution is strictly >> prohibited. If you are not the intended recipient, please notify the >> sender immediately by return e-mail, delete this communication and >> destroy all copies. >> ** >> *** >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs > > > > * > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the > intended > recipient, any use, copying, disclosure, dissemination or > distribution is > strictly prohibited. If you are not the intended recipient, please > notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > * > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Integration with Enterprise Directory Services
Yes, Marty Schleiff at Boeing is working on an RFC for how to represent XRIs in an LDAP directory for that very reason -- to establish standard OIDs for this attribute. LDAP already has a URI attribute type, but downcasting an XRI into a URI just to squeeze it into that attribute type loses the semantics that the XRI is an abstract identifier for the resource. So Boeing wants to establish OIDs for primary-xri (value of the canonical XRI) and alt-xri (value of any other XRI synonym). OpenID URLs really have the same problem -- yes, they are URLs, but they are URLs with the specific property of being OpenID URLs. The LDAP URI attribute doesn't have that semantics. I don't think Marty's on this list but I'm cc'ing him. =Drummond > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of McGovern, James F (HTSC, IT) > Sent: Thursday, January 24, 2008 10:12 AM > To: Johannes Ernst > Cc: specs@openid.net > Subject: RE: Integration with Enterprise Directory Services > > Would even take it to ensuring that directories use a common OID and not > just making up their own attribute. Staying equivalent to Cardspace is a > good thing. > > -Original Message- > From: Johannes Ernst [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 24, 2008 1:00 PM > To: McGovern, James F (HTSC, IT) > Cc: specs@openid.net > Subject: Re: Integration with Enterprise Directory Services > > This doesn't necessarily belong into the core protocol specs, as many > implementations will store OpenIDs in places other than directories. > > However, it would make sense to have a common convention for that ... > perhaps a separate 1-page "standard"? > > > On Jan 24, 2008, at 7:02, McGovern, James F (HTSC, IT) wrote: > > > For CardSpace, MS and other providers store it in the SeeAlso > > attribute. Figured OpenID in the next rev of the spec should talk more > > > about implementation details. > > > > -Original Message- > > From: Drummond Reed [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 23, 2008 11:57 PM > > To: McGovern, James F (HTSC, IT); specs@openid.net > > Subject: RE: Integration with Enterprise Directory Services > > > > James, are you asking about the recommended format for saving an > > OpenID identifier in an LDAP directory? If so, I know Boeing has done > > some work in that area -- I can check with their directory guru. > > > > =Drummond > > > >> -Original Message- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >> Behalf Of McGovern, James F (HTSC, IT) > >> Sent: Wednesday, January 23, 2008 1:47 PM > >> To: specs@openid.net > >> Subject: Integration with Enterprise Directory Services > >> > >> What is the standard recommendation for how identifiers get stored in > > >> enterprise directory services (e.g. LDAP)? > >> > >> ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Integration with Enterprise Directory Services
Would even take it to ensuring that directories use a common OID and not just making up their own attribute. Staying equivalent to Cardspace is a good thing. -Original Message- From: Johannes Ernst [mailto:[EMAIL PROTECTED] Sent: Thursday, January 24, 2008 1:00 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Integration with Enterprise Directory Services This doesn't necessarily belong into the core protocol specs, as many implementations will store OpenIDs in places other than directories. However, it would make sense to have a common convention for that ... perhaps a separate 1-page "standard"? On Jan 24, 2008, at 7:02, McGovern, James F (HTSC, IT) wrote: > For CardSpace, MS and other providers store it in the SeeAlso > attribute. Figured OpenID in the next rev of the spec should talk more > about implementation details. > > -Original Message- > From: Drummond Reed [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 23, 2008 11:57 PM > To: McGovern, James F (HTSC, IT); specs@openid.net > Subject: RE: Integration with Enterprise Directory Services > > James, are you asking about the recommended format for saving an > OpenID identifier in an LDAP directory? If so, I know Boeing has done > some work in that area -- I can check with their directory guru. > > =Drummond > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of McGovern, James F (HTSC, IT) >> Sent: Wednesday, January 23, 2008 1:47 PM >> To: specs@openid.net >> Subject: Integration with Enterprise Directory Services >> >> What is the standard recommendation for how identifiers get stored in >> enterprise directory services (e.g. LDAP)? >> >> >> >> * >> * >> *** This communication, including attachments, is for the exclusive >> use of addressee and may contain proprietary, confidential and/or >> privileged information. If you are not the intended recipient, any >> use, copying, disclosure, dissemination or distribution is strictly >> prohibited. If you are not the intended recipient, please notify the >> sender immediately by return e-mail, delete this communication and >> destroy all copies. >> * >> * >> *** >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs > > > > ** > *** This communication, including attachments, is for the exclusive > use of addressee and may contain proprietary, confidential and/or > privileged information. If you are not the intended recipient, any > use, copying, disclosure, dissemination or distribution is strictly > prohibited. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this communication and > destroy all copies. > ** > *** > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Integration with Enterprise Directory Services
This doesn't necessarily belong into the core protocol specs, as many implementations will store OpenIDs in places other than directories. However, it would make sense to have a common convention for that ... perhaps a separate 1-page "standard"? On Jan 24, 2008, at 7:02, McGovern, James F (HTSC, IT) wrote: > For CardSpace, MS and other providers store it in the SeeAlso > attribute. Figured OpenID in the next rev of the spec should talk more > about implementation details. > > -Original Message- > From: Drummond Reed [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 23, 2008 11:57 PM > To: McGovern, James F (HTSC, IT); specs@openid.net > Subject: RE: Integration with Enterprise Directory Services > > James, are you asking about the recommended format for saving an > OpenID > identifier in an LDAP directory? If so, I know Boeing has done some > work > in that area -- I can check with their directory guru. > > =Drummond > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of McGovern, James F (HTSC, IT) >> Sent: Wednesday, January 23, 2008 1:47 PM >> To: specs@openid.net >> Subject: Integration with Enterprise Directory Services >> >> What is the standard recommendation for how identifiers get stored in >> enterprise directory services (e.g. LDAP)? >> >> >> >> ** >> *** This communication, including attachments, is for the exclusive >> use of addressee and may contain proprietary, confidential and/or >> privileged information. If you are not the intended recipient, any >> use, copying, disclosure, dissemination or distribution is strictly >> prohibited. If you are not the intended recipient, please notify the >> sender immediately by return e-mail, delete this communication and >> destroy all copies. >> ** >> *** >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs > > > > * > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the > intended > recipient, any use, copying, disclosure, dissemination or > distribution is > strictly prohibited. If you are not the intended recipient, please > notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > * > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Integration with Enterprise Directory Services
For CardSpace, MS and other providers store it in the SeeAlso attribute. Figured OpenID in the next rev of the spec should talk more about implementation details. -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 11:57 PM To: McGovern, James F (HTSC, IT); specs@openid.net Subject: RE: Integration with Enterprise Directory Services James, are you asking about the recommended format for saving an OpenID identifier in an LDAP directory? If so, I know Boeing has done some work in that area -- I can check with their directory guru. =Drummond > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of McGovern, James F (HTSC, IT) > Sent: Wednesday, January 23, 2008 1:47 PM > To: specs@openid.net > Subject: Integration with Enterprise Directory Services > > What is the standard recommendation for how identifiers get stored in > enterprise directory services (e.g. LDAP)? > > > > ** > *** This communication, including attachments, is for the exclusive > use of addressee and may contain proprietary, confidential and/or > privileged information. If you are not the intended recipient, any > use, copying, disclosure, dissemination or distribution is strictly > prohibited. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this communication and > destroy all copies. > ** > *** > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Integration with Enterprise Directory Services
James, are you asking about the recommended format for saving an OpenID identifier in an LDAP directory? If so, I know Boeing has done some work in that area -- I can check with their directory guru. =Drummond > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of McGovern, James F (HTSC, IT) > Sent: Wednesday, January 23, 2008 1:47 PM > To: specs@openid.net > Subject: Integration with Enterprise Directory Services > > What is the standard recommendation for how identifiers get stored in > enterprise directory services (e.g. LDAP)? > > > > * > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > * > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
