RE: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group)
Agreed that it makes sense to split it out when the underlying work (XRD 1.0) is ready. =Drummond _ From: David Recordon [mailto:drecor...@sixapart.com] Sent: Sunday, January 04, 2009 11:24 PM To: Drummond Reed Cc: sappe...@gmail.com; 'Nat Sakimura'; 'John Bradley'; specs@openid.net Subject: Re: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group) I'd advocate for waiting until all of the discovery work occurring in OASIS, IETF, and W3C shakes out before we make changes to how OpenID discovery works. I'd much rather make this sort of change once rather than twice. --David On Jan 4, 2009, at 11:14 PM, Drummond Reed wrote: I'm just catching up on holiday mail and wanted to add another +1 to separation of Discovery from AuthN. The sooner the better. =Drummond _ From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On Behalf Of David Fuelling Sent: Friday, December 26, 2008 8:47 AM To: Nat Sakimura Cc: John Bradley; specs@openid.net Subject: Re: Proposal to form Discovery Working Group On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura n-sakim...@nri.co.jp wrote: 2. Separation of OP into Discovery Service and Authentication Service. In the current terminology, OP spans both Discovery Service and Authentication Service. We should be explicit about it. +1. I would like to see discovery services separated from OP services too. John Bradley wrote: Breno, I agree. I recommended separating discovery into a separate doc for 2.1. There didn't seem to be support for the idea at the time, perhaps circumstances have changed and the idea will be accepted now. Regards John Bradley =jbradley ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Separation of Discovery from AuthN (was Proposal to form Discovery Working Group)
I'm just catching up on holiday mail and wanted to add another +1 to separation of Discovery from AuthN. The sooner the better. =Drummond _ From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On Behalf Of David Fuelling Sent: Friday, December 26, 2008 8:47 AM To: Nat Sakimura Cc: John Bradley; specs@openid.net Subject: Re: Proposal to form Discovery Working Group On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura n-sakim...@nri.co.jp wrote: 2. Separation of OP into Discovery Service and Authentication Service. In the current terminology, OP spans both Discovery Service and Authentication Service. We should be explicit about it. +1. I would like to see discovery services separated from OP services too. John Bradley wrote: Breno, I agree. I recommended separating discovery into a separate doc for 2.1. There didn't seem to be support for the idea at the time, perhaps circumstances have changed and the idea will be accepted now. Regards John Bradley =jbradley ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal to create the TX working group
* Conformance requirements for other data transfer protocol bindings * Security, threats and Risk analysis * Perform Security Risk analysis and profiles for best practice Out of scope * Term negotiation: Actual negotiation of the terms of a contract should be dealt with out-of-band or by other specifications. * General purpose data type identifiers: this should be determined on a per-community bases using other specifications such as OpenID Attribute Exchange. * Assurance programs or other identity governance frameworks. * It is the intent that this specification be usable by any trust community, whether it uses conventional PKI hierarchies, peer-to-peer trust mechanisms, reputation systems, or other forms of trust assurance. The specification of any particular trust root, trust hierarchy, or trust policy is explicitly out of scope. (iv) Proposed List of Specifications: TX 1.0, spec completion expected in January 2009. (v) Anticipated audience or users of the work: Implementers of OpenID Providers and Relying Parties, especially those who require security and accountability features to exchange sensitive customer information (e.g. personally identifiable information and credit card numbers) responsibly among trusted parties. (vi) Language in which the WG will conduct business: English. (vii) Method of work: E-mail discussions on the working group mailing list, working group conference calls, and possibly face-to-face meetings at conferences. (viii) Basis for determining when the work of the WG is completed: Draft 1 will be evaluated on the basis of whether they increase or decrease consensus within the working group. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope. (b) Background Information. (i) Related work being done by other WGs or organizations: * LIberty Alliance Identity Governance Framework (IGF) 1.0 http://www.projectliberty.org/liberty/content/download/4329/28939/file/libe rty-igf-draft-1.0-2008-06-21.zip Draft * XML Advanced Electronic http://www.w3.org/TR/XAdES/ Signatures (XAdES) (ii) Proposers: Drummond Reed, [EMAIL PROTECTED], Cordance/Parity/OASIS (U.S.A) Henrik Biering, [EMAIL PROTECTED], Netamia (Denmark) Hideki Nara, [EMAIL PROTECTED], Tact Communications (Japan) John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section (Canada) Mike Graves, [EMAIL PROTECTED], JanRain, Inc. (U.S.A.) Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute, Ltd.(Japan) Robert Ott, [EMAIL PROTECTED], Clavid (Switzerland) Tatsuki Sakushima, [EMAIL PROTECTED], NRI America, Ltd. (U.S.A.) Toru Yamaguchi, [EMAIL PROTECTED], Cyboze Lab (Japan) Editors: Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute, Ltd. (iii) Anticipated Contributions: (1) Sakimura, N., et. al http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust- exchange-1_0.html?root=openidtx OpenID Trusted data eXchange Extention Specification (draft), Oct. 2008. [TX2008]. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: This is user's URI for Assertion Quality Extension
Shade, here's the nut of the problem: directed identity in OpenID Authentication 2.0 means nothing more than: The user logging in to your site is not asserting the URI they have typed in; instead the OP will tell you the URI for the user. Then _any_ URI then returned from the OP *is* then the user's URI. For example, I could enter myopenid.com when logging into an RP, have the RP discover the myopenid.com directed identity service there, and then instruct myopenid.com to return xri://=!F83.62B1.44F.2813 as my URI (which is the XRI i-number for my i-names =drummond and =drummond.reed). So the RP would end up exactly the same identifier an RP would dicover if I logged in as =drummond. That's the way directed identity is designed to work. It's not necessarily about anonymity -- it's about letting the user choose their URI at the OP rather than typing it into the RP. So net net is I don't think there's any way to ascertain a real URI even if there was such a thing. It can and should be the user's choice what URIs he/she shares with what sites. If a site has a particular reason to know that a user has shared a particular URI with another particular site, that's different -- and the OpenID protocol could be used to prove that. But I don't think that's what you're asking. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of SitG Admin Sent: Friday, September 05, 2008 1:48 PM To: specs@openid.net Subject: RE: This is user's URI for Assertion Quality Extension None of them were assumed by me; I don't consider the use-case to rely on any of them. 1) A directed identity URI creates a situation where the RP *doesn't know* whether it is a real URI or not. (This assumption has been hypothetically mitigated by an idea that occurred to me during this discussion, of performing discovery on the asserted URI as normal and looking for any OpenID headers.) 2) There are other reasons for using Directed Identity (such as being able to give all users the same URL to use instead of asking them to figure out what a URL would look like with their username substituted for the example text), reasons that have nothing to do with privacy. RP's may, at their discretion, encourage use of Directed Identity (adoption of the feature, where offered at the site hosting user's URI) by treating those who *don't* use it (when available) as second-class citizens! Or just ignore (not even request, really) this information completely. Like any of the other quality assertion strings (biometrics, phone), it's not there because ALL the Relying Parties MUST use it, but because *some* of us *may* want to. Whether a RP discriminates and whether it's for or against is not dictated by this proposal. 3) Do you know what the web will look like if no user ever employs the same URI at more than one site? The same walled gardens we have right now, that's what. One account per site. OpenID doesn't provide Identity in any meaningful way (and certainly not Open) if we don't see users employing at least one URI on at least two sites. Providing the means to detect when they're using a unique URI over the long term, so they can at least be educated about the implications (if not encouraged to practice a consistent URI), does not strike me as a bad thing. -Shade ___ 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: IDMML (was RE: Using email address as OpenID identifier)
George Fletcher wrote: I think relying party sites that support OpenID could do more to make it clear on their home pages that they support OpenID (as often it's hidden behind another click). This could be as simple as some link tags that advertise support for OpenID. Maybe a link to the XRDS doc describing the services of the site. Then the identity agent can discover the relying party OpenID return_to endpoint and log the user in directly. Can be used to solve a phishing problem and makes the experience easy for the user. Some related thoughts http://practicalid.blogspot.com/2007/06/clients-to-rescue.html http://practicalid.blogspot.com/2007/06/passive-identity-meta-system- markup.html Drummond wrote: George, I read your two posts with great interest...and then noticed that they were last summer! You are a man ahead of your time. Where has discussion of your IDMML gone since your posts? George wrote: Unfortunately, not as far as I'd like :( I've not been able to get back to the ideas and take them farther. With the other things that have happened in the last 6 months there are needed revisions. Maybe this could be a discussion at IIW (if there is enough interest)? At the time there was less consensus around XRDS as a service description/meta-data markup. With that changing, the time is better to move this forward. I suspect there are significant synergies with what Peter hinted at in the work with XRDS, IDP Discovery, and SAML. It would be great if identity agents could be the glue that binds the different identity systems together for the user (until we on the technology side get closer to real convergence:). George, I agree that several things have evolved which could make an IDMML practical now. Seems like a very good topic for IIW. I just put it on the list of proposed sessions: http://iiw.idcommons.net/index.php/Proposed_Topics_2008a =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Problems with OpenID and TAG httpRange-14
-Original Message- From: Noah Slater [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 1:43 AM To: Drummond Reed Cc: specs@openid.net Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14 Noah, you are in the right place (and the General list is the wrong place, which is why I have removed that cc). Okay, thank you. Once those groups start, they will each have dedicated mailing lists. In the meantime, this is the list for discussing any spec issues. So far one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on the thread you started. Im a little confused about what this means. Does this mean that this issue will not get properly looked at until such time as the new WGs have been set up? It doesn't mean it won't get looked at or discussed here. However any formal changes to the specifications must wait until these WGs are started. Is there anywhere further to go from here? No, this is the right place, and until the WGs are started, any discussion should take place on this list. I'll bring it up at the next OpenID Foundation board meeting (this Thursday) so board members are aware of this issue. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Problems with OpenID and TAG httpRange-14
Brad, You are correct, the OIDF is not a technical forum. Its responsibility is to help facilitate the operation of the technical forum and the applicable IPR policy. The issue I was pointing out was that since the new IPR policy was adopted in December, which calls for explicit workgroups for each spec, no place has it been published how those WGs can be formed and operated by community members in accordance with the IPR policy. So none of this is under the control of the OIDF, but it is their responsibility to help community members make it happen. I just sent a note the OIDF board mailing list suggesting this is something that needs attention on the call this week. =Drummond _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Fitzpatrick Sent: Monday, March 10, 2008 11:01 AM To: Drummond Reed Cc: Noah Slater; specs@openid.net; [EMAIL PROTECTED] Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14 Drummond, I was under the impression that the OpenID Foundation wasn't a technical forum. Is that not true? - Brad On Mon, Mar 10, 2008 at 10:46 AM, Drummond Reed [EMAIL PROTECTED] wrote: -Original Message- From: Noah Slater [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 1:43 AM To: Drummond Reed Cc: specs@openid.net Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14 Noah, you are in the right place (and the General list is the wrong place, which is why I have removed that cc). Okay, thank you. Once those groups start, they will each have dedicated mailing lists. In the meantime, this is the list for discussing any spec issues. So far one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on the thread you started. Im a little confused about what this means. Does this mean that this issue will not get properly looked at until such time as the new WGs have been set up? It doesn't mean it won't get looked at or discussed here. However any formal changes to the specifications must wait until these WGs are started. Is there anywhere further to go from here? No, this is the right place, and until the WGs are started, any discussion should take place on this list. I'll bring it up at the next OpenID Foundation board meeting (this Thursday) so board members are aware of this issue. =Drummond ___ 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: [OpenID] Problems with OpenID and TAG httpRange-14
Exactly, David, that's the process I was referring to. It should be as lightweight as possible. I guess the main question is, is there sufficient interest in either a bugfix release or a more significant new release to start up a mailing list on OpenID Authentication yet? =Drummond -Original Message- From: David Recordon [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 12:15 PM To: Drummond Reed; Brad Fitzpatrick Cc: Noah Slater; OpenID specs list; DeWitt Clinton Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14 I don't see why changes would really need to wait, if there is an interested group of people then lets spin up a mailing list and get participants to agree to the IP policy. The entire goal of having working groups and seperate mailing lists is to help ensure that future OpenID specs are not encumbered with intellectual property issues. The easiest, and most common, way to do this is creating seperate technical working mailing lists based around related topics or a specification. This allows people to choose where they wish to participate since the requirement of posting to one of these lists is agreeing that your contributions are being made under the OpenID IPR Policy. This list (specs@openid.net) is a great place to identity issues that need addressing and figuring out who wants to work on solving them. Once that happens, I have no problem helping to make it legit so that the resulting spec is good from an IP perspective. --David On Mar 10, 2008, at 12:46 PM, Drummond Reed wrote: -Original Message- From: Noah Slater [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 1:43 AM To: Drummond Reed Cc: specs@openid.net Subject: Re: [OpenID] Problems with OpenID and TAG httpRange-14 Noah, you are in the right place (and the General list is the wrong place, which is why I have removed that cc). Okay, thank you. Once those groups start, they will each have dedicated mailing lists. In the meantime, this is the list for discussing any spec issues. So far one OpenID Authentication 2.0 editor, Johnny Bufu, has commented on the thread you started. Im a little confused about what this means. Does this mean that this issue will not get properly looked at until such time as the new WGs have been set up? It doesn't mean it won't get looked at or discussed here. However any formal changes to the specifications must wait until these WGs are started. Is there anywhere further to go from here? No, this is the right place, and until the WGs are started, any discussion should take place on this list. I'll bring it up at the next OpenID Foundation board meeting (this Thursday) so board members are aware of this issue. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Public Review of Extensible Resource Identifier (XRI) Resolution V 2.0 - 15 day review
FYI - XRI Resolution 2.0 is now undergoing one more 15-day public review after incorporation of feedback from the previous 60-day public review in December and January. Links to both the change-marked and clean version of the spec are in the announcement below. =Drummond -Original Message- From: Mary McRae [mailto:[EMAIL PROTECTED] On Behalf Of Mary McRae Sent: Monday, March 10, 2008 6:31 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [members] Public Review of Extensible Resource Identifier (XRI) Resolution V 2.0 - 15 day review To OASIS members, Public Announce Lists: The OASIS eXtensible Resource Identifier (XRI) TC has recently approved the following specification as a Committee Draft and approved the package for public review: Extensible Resource Identifier (XRI) Resolution Version 2.0 The public review starts today, 11 March 2008, and ends 26 March 2008. This specification was previously submitted for a 60-day public review on 2 December 2007[1]; this 15-day review is limited in scope to changes made from the previous review. All changes are highlighted. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. More non-normative information about the specification and the technical committee may be found at the public home page of the TC at: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked Send A Comment at the top of that page, or directly at: http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=xri. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at: http://lists.oasis-open.org/archives/xri-comment/. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. The specification document and related files are available here: Change-Marked/Comments: http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution- V2.0-cd-03-diff.doc Editable Source (Authoritative): http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution- V2.0-cd-03.doc PDF: http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution- V2.0-cd-03.pdf HTML: http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution- V2.0-cd-03.html The RelaxNG schema files, that are included normatively in the specification document, are available as separate files at: http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xrd.rnc http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xrds.rnc Additionally, W3C schema files are available as separate files at: http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xrd.xsd http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xrds.xsd OASIS and the eXtensible Resource Identifier (XRI) TC welcome your comments. --- Mary P McRae Manager of TC Administration, OASIS email: [EMAIL PROTECTED] web: www.oasis-open.org [1] http://lists.oasis-open.org/archives/tc-announce/200712/msg2.html - ___ 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: specs@openid.net 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
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
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
RE: Service Key Discovery 1.0
Masaki, Peter has a good point -- the XRDS keyinfo discovery mechanism, specified in section 10.2 (SAML Trusted Resolution) of XRI Resolution 2.0 Committee Draft 02 (http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf ), deals with DNS poisoning by using signed SAML assertions (including the ds:keyInfo element) for each authority in the resolution chain. So presuming HTTPS is used for the first root authority call, you should be good all the way down the chain as long as signatures verify. (Peter's also right that libraries have not implemented it yet, but that may be changing soon as demand for secure key discovery rises...) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Davis Sent: Monday, January 21, 2008 6:33 AM To: NISHITANI Masaki Cc: specs@openid.net Subject: Re: Service Key Discovery 1.0 FWIW, the XRI form of openID's provides just such a mechanism, where- by the publisher of the XRD signs all (or a part of) the XRDS, tho i know of few libraries today which support trusted resolution[1]. =peterd [1] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0- cd-02.pdf On Jan 21, 2008, at 5:38 AM, NISHITANI Masaki wrote: Hi all. What concerns me these days is about secure data exchange over OpenID for serious services and about this theme, I came upon an specification, secure key discovery 1.0 For my understanding, this spec is about implementing security framework on OpenID world and is still very draft. Now I'd like to figure out some point I found. - In this, the url of the public key is defined to be in the XRD document and entities will make another request for the url to retrieve the public key itself. This gives bad people a chance to pass off a fake key with poisoning the end-user's DNS. How about to put public key itself in the XRD or someone else the entity trusts (a key server)? The entity only has to manage SSL certificate fingerprints of XRD authorities or trusting key servers. - With secure key discovery, we do have to use association or verification message no longer. I think we can optimize OpenID protocol using digital signature with public keys. This can be done with following procedure. 1. End-user enter its OpenID in RP site. 2. RP resolve the id and select the user's OP. 3. In the same time, RP retrieve the OP's public key. 4. RP generate a challenge (maybe the user's http session id) 5. RP send the id to the OP via http redirection. 6. OP authenticate the user and sign to the challenge with OP's secret key. 7. OP send the assertion including the signed challenge back to the RP via redirection. 8. Now RP can verify the assertion with the signature using OP's public key. The good thing about this sequence is not only reducing network traffic, but this can be a solution against man-in-the-middle attacks, to which OpenID has principle vulnerability. I think this spec can be quite useful for the next version of OpenID protocol. Does someone know the status of it? =masaki ___ 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: OpenID Email Discovery
Phillip, what do you mean by Until the IPR commitments necessary to allow that change are made there is no standard. The OASIS XRI TC has operated under a royalty-free IPR policy since the day it was formed (see the language in the charter, http://www.oasis-open.org/committees/xri/charter.php), and subsequently adopted to the RF Limited IPR Policy when OASIS update its IPR rules (document at http://www.oasis-open.org/committees/xri/ipr.php). So even though the final spec in the XRI 2.0 suite - XRI Resolution 2.0 Committee Draft 02 - is now in public review (http://lists.oasis-open.org/archives/xri/200712/msg1.html), so we should be proceeding to an OASIS Standard vote on XRI 2.0 this spring, there shouldn't be anything standing in the way of immediate adoption, as has been happening in a number of open source efforts. Or is there something about the OASIS standardization process that I'm missing? =Drummond _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip Sent: Thursday, January 03, 2008 3:03 PM To: Peter Davis Cc: OpenID specs list Subject: Re: OpenID Email Discovery NAPTR is an ietf proposed standard but there is no deployed base. SRV has been supported in windows since 2000 and bind since before then. XRI is a specification, not an OASIS recommendation. Until the IPR commitments necessary to allow that change are made there is no standard. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Peter Davis [mailto:[EMAIL PROTECTED] Sent: Thursday, January 03, 2008 02:07 PM Pacific Standard Time To: Hallam-Baker, Phillip Cc: Eran Hammer-Lahav; OpenID specs list Subject:Re: OpenID Email Discovery actually, NAPTR RR's would be a better fit, as the unique-part of an openID may be in the local-path part of a URI, not the hostname... of course, if a users openID changes, so too might their underlying DNS name, and then DNS won't help you at all there. XRI is better situated to solve that use case. =peterd On Jan 3, 2008, at 4:48 PM, Hallam-Baker, Phillip wrote: This is the function of the existing DNS SRV record. _openid.example.com SRV 1 1 1 1 openid1.example.com The Internet has an architecture already. Use it, don't try to reinvent it. From: [EMAIL PROTECTED] on behalf of Eran Hammer-Lahav Sent: Thu 03/01/2008 4:01 PM To: 'OpenID specs list' Subject: OpenID Email Discovery (The full story is posted at http://www.hueniverse.com/hueniverse/ 2008/01/addressing-open.html but this contains the technical parts of the post). This proposal adds Email Discovery allowing users to use their email address as an OpenID. . We need to map between the email to the OpenID identifier and this is where DNS comes in. DNS already has a system for resolving email addresses into an actual server - email resolution using an MX record. Why not add a new record type for OpenID. Basically another way to perform OpenID discovery that is all about making it user- friendly. All that is needed is a URL the site performing discovery can append the email to and treat it as an OpenID identifier. This can be done using a OpenID TXT record: 'OpenID [username rule] [priority] [URL]' where [username rule] is a wildcard expression used to match the username part of the email (everything up to the '@'), [priority] is the MX-like priority value, and [URL] is the URL used to generate the OpenID identifier. The URL uses '*' to indicate where the username is inserted, and '**' to indicate where the full, URL-encoded, email address is inserted (both optional). For example: example.com TXT 'OpenID * 10 http://*.example.com/' example.com TXT 'OpenID joe 10 http://example.org/openid?**' Which reads: for any email address '@example.com' other than 'joe' use 'http://username.example.com/' as the OpenID identifier. For email address '[EMAIL PROTECTED]' use 'http://example.org/openid?joe% http://example.org/openid?joe%25 40example.com' as the OpenID identifier. Rules are processed first based on the username rule match (in order of match closeness) and then on priority which is used in the same manner as MX records priority. . There are many ways to implement identity delegation, but in the context of email identifiers and simplifying the user experience, the idea is to move the delegation mapping to the OpenID provider. When users sign-up for a new OpenID, they will be given the option, perhaps as a premium paid service, to make the OpenID provider map incoming identity checks for the user email address with their local OpenID identifier. So instead of the users telling the site about their local identity (using delegation), the OpenID provider will perform the mapping. In the above example, '[EMAIL PROTECTED]' has his OpenID managed by 'example.org'. When signing up for an OpenID at 'example.org', Joe
RE: [Idschemas] identity schema element metadata:using existingspecifications
+1 to Nat's point about supporting virtual aggregation under user control. Chris, on the larger question you ask, the Data Sharing Summit was not about how others that have your data can share it, but rather about how you can control and share that data the way you want with whom you want. To be clear, not all the attendees of the DSS subscribe to your vision of 100% user-centric aggregation. A number of them were services that provide some type of aggregation in which the user is in control, but the site is still able to offer services/applications/other-value-adds based on doing this aggregation on the user's behalf. Several new social network aggregation services like Pownce have this philosophy. They would say that the user elects to trust them as a service provider just like the user elects to trust an IdP (or OP as OpenID calls them). Anyway, I just wanted to clear up any misconception about what the Data Sharing Summit was about. Without that context, I agree that name could make it look like a really Bad Idea. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nat Sakimura Sent: Sunday, September 09, 2007 10:18 PM To: Chris Drake Cc: 'OpenID specs list'; 'ID Schemas' Subject: Re: [Idschemas] identity schema element metadata:using existingspecifications Hi, Instead of having one single master copy at the IdP, I would prefer one single piece of each information disparsed over the network (optionally with opaque identifiers) and having IdP managing the links so that I can control all the pieces from one place. I feel that having everything at one place is too risky. =nat Chris Drake wrote: Hi, Having missed the summit - can anyone tell if there was any dissent or scaremongering going on? The idea of assisting everyone who's collecting information about me, to share it easily, seems like an exceptionally Bad Idea (tm). If anyone's building anything that assists these companies to give up or relinquish their collection of my data, in favor of letting me hold the one single master copy if it myself, on my chosen IdP, and to let me arbitrate who can use it, when, and how - now *that* would be something to congratulate people about. Search google/google-news for paper shredder ... Kind Regards, Chris Drake, =1id.com Saturday, September 8, 2007, 5:33:20 PM, you wrote: DR Mark, DR I just wanted to say that based on what I learned about them at the Data DR Sharing Summit (http://datasharingsummit.com) today, and what I read on my DR first pass tonight, these are fine pieces of work that really push the ball DR forward. DR Hats off to you. DR =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:idschemas- [EMAIL PROTECTED] On Behalf Of Mark Wahl Sent: Thursday, September 06, 2007 6:05 PM To: ID Schemas Cc: OpenID specs list Subject: [Idschemas] identity schema element metadata: using existingspecifications I'm reformatting the table of identity schema metadata, located at http://idschemas.idcommons.net/moin.cgi/MetaData, into a pair of more compact and usable specifications. One spec describes where the existing well-known metadata (e.g., Dublin Core) should be used when describing identity schemas and their schema elements (i.e., attribute types and claim types). The other spec will describe how to represent identity schema metadata for which there is no pre-existing well-known specification. I've attached a copy of the first draft of the Identity Schema Element Metadata: Using Existing Specifications. Mark Wahl Informed Control Inc. DR ___ DR specs mailing list DR specs@openid.net DR 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Do We Agree on the Problem We're Trying to Solve?
Multiple, redundant identifiers is what canonical ID mapping provides. It doesn't require a master directory; it's as distributed as OpenID itself, i.e., it simply provides a way to map a reassignable URL or XRI to a persistent URL or XRI. Given the right practices, it solves both A and B. The cost can be, as Josh points out, an extra round trip on discovery. However this can be avoided for certain pairs of the reassignable and persistent identifiers. See my next reply to Josh's message. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Friday, June 08, 2007 12:33 PM To: Johannes Ernst Cc: specs@openid.net Subject: Re: Do We Agree on the Problem We're Trying to Solve? Multiple, redundant identifiers solves B without requiring a master directory. On 8-Jun-07, at 11:06 AM, Johannes Ernst wrote: Such as? On Jun 8, 2007, at 10:55, Dick Hardt wrote: There are ways to solve B that don't really solve A. In fact, I think the only way to solve B that does not require a master directory is orthogonal to solving A. -- Dick On 8-Jun-07, at 10:49 AM, Johannes Ernst wrote: I would suggest that any solution to B is also very likely a solution to A. Anybody disagree? If so, I'd suggest that we should either solve A and B at the same time, or not at all. On Jun 8, 2007, at 10:42, Dick Hardt wrote: At IIW we[1] decided we wanted to solve (A) and that (B) would be nice to solve, but we were ok to wait for a future version to resolve, as when we discussed (B), resolving looked much harder then it seemed at first. I'm not certain of where we are now. -- Dick [1] those present when we met about how to solve recycling ... On 8-Jun-07, at 10:35 AM, Recordon, David wrote: I'm not sure if we all think we're trying to solve the same problem. The two problems that have been discussed are: A) Identifier recycling normally in large user-base deployments. i.e. insert big company needs a way to give 'TheBestUsernameEver' to a new user if it has not been used in some period of time. B) Losing control of your own domain name whether that be via someone stealing it or just that you don't want to have to pay for it forever. Have we made a decision as to if we're looking for a solution to solve both of these problems, only A, or only B? --David ___ 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 ___ 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: Do We Agree on the Problem We're Trying to Solve?
Dick Hardt wrote: Canonical IDs do not solve B. I would agree with that one. Obviously the XRI architecture assumption (not as radically decentralized as OpenID) makes that less of a problem in an XRI context. Of course, some would say that that assumption is a problem in itself. Where was it asserted that XRI architecture is not as radically decentralized as OpenID? Fen made the point yesterday that XRI architecture is *less* centralized that DNS. The choice of identifier authorities under URL architecture is DNS registries or IP addresses. XRI architecture supports both of those and adds two more: XRI registries and p2p authorities. So it's getting less centralized, not more. Due to the influence of OpenID and other URL-centric technologies, in the XRI 3.0 discussions already under way, the TC is looking at formalizing XRI resolution of HTTP and HTTPS URIs (URLs) and Handles. Wouldn't it be cool for OpenID libraries be able to simply call a resolver to do XRDS resolution of any OpenID identifier (URL or XRI), Canonical ID verification (URL or XRI), and OpenID service endpoint selection all in one function? =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Do We Agree on the Problem We're Trying to Solve?
Drummond Reed wrote: Multiple, redundant identifiers is what canonical ID mapping provides. It doesn't require a master directory; it's as distributed as OpenID itself, i.e., it simply provides a way to map a reassignable URL or XRI to a persistent URL or XRI. Dick Hardt wrote: The persistent URL or XRI *is* a master directory. What do you do when the persistent identifier is compromised, goes out of business ... That is problem B. Canonical IDs do not solve B. I completely agree that B is a hard problem. However Canonical IDs solve B if the identifier authority for the Canonical ID follows business and operational practices intended to solve B. For example -- and this is only one example, other identifier authorities that adopt these or similar practices to solve B -- XDI.org spent several years developing policies that ensure that as an identifier authority, the Canonical IDs (global i-numbers) assigned by the XDI.org global XRI registries follow these policies: 1) Global i-numbers and their registration policie are designed explicitly for persistent identifiers that are never reassigned and administered by an international public trust organization (XDI.org) for which this is the primary responsibility. 2) If the i-broker serving as the end-user's registrar goes out of business, the global i-number is not compromised because, like a DNS name, it is portable, i.e., the registrant can move it to another accredited i-broker. In other words, the concern about going out of business becomes a concern only about the entire infrastructure going out of business. 3) Strong authentication is used in i-broker-to-registry communications to ensure that only accredited and authoritative i-brokers make changes to global registrations, and accredited i-brokers compete under market conditions to offer the best and most flexible means of authenticating registrants, thereby minimizing the risk of a registrant losing control of their global i-number. 4) Every global i-number registration also enables the registrant to register private contact data with an independent third-party trustee (their contact data custodian) to provide an independent third-party channel for authentication. For reference, see the XDI.org Global Services Specifications site at http://gss.xdi.org. It's not a perfect solution, but I would argue (my well-known bias aside) that it's a practical one. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
Johnny Bufu wrote: We did look at this (with Drummond) in December. The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Martin Atkins wrote: Indeed, CanonicalID verification would be necessary, but it's already necessary if you want to accept XRI-based logins anyway. Last time we were talking about this CanonicalID verification for XRI was not yet specified. Is it now specified somewhere? Martin, it's been specified in draft form since last October on the XRI TC wiki at: http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification The content there was moved week before last into the first editor's draft of XRI Resolution 2.0 Working Draft 11 at: http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v2.0- wd-11-ed-01.doc The new Canonical ID Verification section is #11. Note that the verification rules currently only cover if the XRDS is discovered from an XRI. In the second editor's draft, due this Wednesday, we will add rules for verification if the XRDS is discovered from a URL. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Review of Yadis section in XRI Resolution 2.0 WD11
Johnny, David, Rowan: Thanks much for the excellent feedback. I'm tied up in meetings through tomorrow but by Monday I'll make the suggested updates and roll this into the second editor's draft of XRI Resolution 2.0 Working Draft 11, which we aim to post by next Wednesday. =Drummond -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Thursday, May 31, 2007 7:52 PM To: Recordon, David Cc: Drummond Reed; OpenID specs list Subject: Re: Review of Yadis section in XRI Resolution 2.0 WD11 On 31-May-07, at 5:34 PM, Recordon, David wrote: I'd recommend adding a section which pulls together the HEAD and GET methods and describes how'd they be used in conjunction. In the interest of keeping it light and simple to process, I believe it would be enough to make this explicit just before 8.1 by saying that any of the two protocols MAY be attempted by an RP (plus fixing the fallback from HEAD to GET). Also explicitly pointing out that a URL hosting a XRDS document only is required to implement one or more of the discovery mechanisms Not one or more; GET is REQUIRED, HEAD is OPTIONAL in Yadis. This too can be specified inline in sections 8.1 / 8.2. whereas a service requesting XRDS documents must implement all of the different methods. An RP may choose to only do GET and not care about the more efficient (but optional on the server side) HEAD. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
John Panzer wrote: Has there been a discussion about an extension to map to/from i- numbers via AX? If there were a generic attribute you could stuff an i- number or a hash of an internal ID in there to help solve the disambiguation problem. Alternatively it'd be nice to have a way to ask when the account was created, if the OP is amenable. Martin Atkins wrote If you're going to use i-numbers, then there's no reason at all not to use the XRD CanonicalID element. The same mechanism that's used to map i-names onto i-numbers can also be used to map URLs onto i-numbers, or URLs onto other URLs. I'm sure Drummond can talk in more detail about this. We did discuss it briefly at IIW, but once the majority had decided that the fragment approach was the way to go we didn't get a chance to investigate this further. Johnny Bufu wrote; We did look at this (with Drummond) in December. The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Johnny: Martin, Gabe, and I discussed this at IIW, and the CanonicalID verification process that's specified in the XRI Resolution 2.0 Working Draft 11 specification (of which the first editor's draft has now been posted - see below) could be applied even if the XRDS was discovered via a URL. To do this, RP code would need to confirm the CanonicalID i-number was authoritative for the XRDS, which is essentially the same process the RP has to go through anyway when the OP returns a different identifier than the one the user originally entered at the RP (such as in the directed identity flow). In the first editor's draft of WD11, we only specified Canonical ID verification when an XRDS was discovered from an XRI. But in the second editor's draft (due early next week), we could add text specifying how to do Canonical ID verification when the XRDS is discovered from a URL. Although it's not yet content complete, you can review the Canonical ID verification section (section 11) as well as the Yadis section (section 8) in the first editor's draft of WD11 at: http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v2.0- wd-11-ed-01.doc To make it easier to review, we've also posted section 8 (the Yadis section) as a wiki page on the XRI TC wiki. See my next message about that. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
Johannes: What about the point Dick posted earlier in this thread, that the problem with using a public key is if the private key gets compromised? Persistent identifiers need to persist independent of any attribute changing or being revoked. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 9:54 PM To: OpenID specs list Subject: Re: Specifying identifier recycling On May 30, 2007, at 21:02, Johnny Bufu wrote: ...The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Public keys ... public keys ... with the added benefit that no centralized or trusted verification service needs to be employed whatsoever ... Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Review of Yadis section in XRI Resolution 2.0 WD11
As discussed at IIW, the OASIS XRI TC is now moving swiftly to close and vote on the XRI Resolution 2.0 spec (which has been at the Working Draft 10 stage during the entire evolution of OpenID Authentication 2.0) so it can be referenced by OpenID Authentication 2.0 when it goes final. To that end, the first editor's draft of Working Draft 11 has been posted [1]. It's not quite content complete (all major changes have been incorporated; we're now working on the smaller stuff), so we're not asking folks to review the whole thing yet (many OpenID folks think it's too long anyway ;-). However it would be great to get feedback on the new section 8 that incorporates the Yadis protocol. Per discussions with the OpenID editors last fall, the XRI TC is including this in the XRI Resolution spec so everything about XRDS documents and their discovery is referenceable in an open public OASIS spec, even if only URLs and no XRIs are involved. To make this new section easy to review, we've put it on the XRI TC wiki at: http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris It's pretty short and sweet, mostly because XRDS documents and their context and usage are defined elsewhere in the spec. So this section just defines the URL-based discovery protocol, which is the meat of the Yadis 1.0 spec. The wording has been restructured slightly to fit the OASIS spec format, however the only normative change was to make the recommendation to include the application/xrds+xml Accept header in the HEAD or GET request a SHOULD instead of a MAY. The XRI TC felt this was justified to encourage efficiency -- feel free to push back if you think that's the wrong call. Since only XRI TC members can write to the wiki (due to OASIS IPR rules), please post any feedback here on the specs list and we'll reflect it on the wiki page as quickly as we can (I myself will be offline in meetings tomorrow but back online tomorrow night). Thanks, =Drummond [1] http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v2.0- wd-11-ed-01.doc ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: attribute exchange value encoding
Johnny Bufu wrote: While at IIW, I asked around what people thought about the encoding mechanisms we've added recently, in order to allow for transferring any data types. The consensus was that everyone would prefer something simpler and lighter. So I've rewritten the encoding section, such that: - for strings, only the newline (and percent) characters are required to be escaped, (to comply with OpenID's data formats), using percent-encoding; - base64 must be used for encoding binary data, and defined an additional field for this: openid.ax.encoding.alias=base64 Please review section 3.3 Attribute Values to see if there are any issues. One remaining question is about the choice of encoding for strings. Percent-encoding (RFC3968) seems the simplest from a spec perspective, however some libraries provide (better) support for the older URL-encoding (RFC1738), which throws '+' characters into the mix. Which do you think would work best for implementers, users, and would cause less interop problems? Johnny, FWIW, encoding + can be a hassle as it's a legal character in media type values and is also sometimes used for spaces. I'd vote for pure RFC3986 percent-encoding. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: HTML discovery: SGML entities and charsets
Peter Watkins wrote: snip My concrete suggestion: replace the current language Other characters that would not be valid in the HTML document or that cannot be represented in the document's character encoding MUST be escaped using the percent-encoding (%xx) mechanism described in [RFC3986]. with this: Any character in the href attributes MAY be represented as UTF-8 data escaped using the percent-encoding (%xx) mechanism described in [RFC3986]. Characters with Unicode values greater than u007E MUST be represented as UTF-8 data escaped using the percent-encoding (%xx) mechanism described in [RFC3986]. For instance, the character ä (umlaut a, Unicode u00E4) MUST be represented as a six-character string like %C3%A4 as suggested by RFC2718. Peter, I agree UTF-8 encoding before percent-encoding must be specified, as otherwise you don't know how to interpret the percent-encoded characters. However, since RFC 3987 (the IRI spec) already specifies UTF-8 encoding before percent-encoding, couldn't we just specify it by reference to both RFC 3986 and 3987, e.g.: Any character in the href attributes MUST be a valid URI character as specified by [RFC3886]. If any character outside the valid URI character set is included, it MUST be encoded using the percent-encoding (%xx) mechanism defined in section 2.1 of [RFC3986] after first being UTF-8 encoded as specified in [RFC3987]. For instance, the character ä (umlaut a, Unicode u00E4) MUST be represented as a six-character string like %C3%A4 as suggested by RFC2718. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: PROPOSAL schema.openid.net for AX (and other extensions)
On 9-Apr-07, at 5:24 PM, Recordon, David wrote: Yes, I agree an upgrade path from SREG is needed. We could however do something as simple as http://openid.net/specs/openid-simple-registration- extension-1_0.html#ni ckname for the existing SREG fields. Dick wrote: by making this a fragment, you force a requirement that Mark's tool has to be able to dig into a document and find the anchor as opposed to the attribute being self contained -- a complication I am not sure we want to deal with at this point in the meta-data why not have a page that maps the existing SREG to the AX attributes we have already defined? why create yet-another set of attributes? Myself, I think a developer would like to look in ONE place to find all the common web related attributes she will likely need so that she can build her app and not have to go looking across a dozen different sources to write some code. There will definitely be attributes that are for specific communities, so the developer will need to look in a few places, but why make it harder then it needs to be at this point in time? A number of people have spoken up to vote +1 to use schema.openid.net. Given that you have the magic wand David, are you going to let the community progress or do we have to keep arguing with you until one party wears out and gives up? I haven't spoken up yet, but I feel strongly that creating YAAD (Yet Another Attribute Dictionary) for OpenID is a bad idea. OpenID is a wonderful force for driving towards attribute dictionary convergence, but that is not the focus of OpenID. It is however the direct focus of the Identity Commons Identity Schemas Working Group (site: http://idschemas.idcommons.net/, charter: http://wiki.idcommons.net/moin.cgi/IdentitySchemasCharter). Since the problem of attribute interop is larger than OpenID, I strongly recommend that those of us in the OpenID community that want to see this problem solved join the idschemas mailing list (http://mail.idcommons.net/cgi-bin/mailman/listinfo/idschemas) and work out the attribute dictionary (complete with synonyms) there. That way OpenID, CardSpace, XDI, and any technology that needs to move around standard profile data will have half a prayer of actually doing it interoperably. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: in favor of allowing a fragment in a URI for metadata for anattribute type
+1 as well. Very well articulated. An interesting side note: XRI supports a # fragment for backward compatibility with URI/IRI syntax, but in practice its rarely used since XRI syntax is already polyarchical, i.e., any XRI can be put in the context of another XRI. # is just one such context (document local). So XDI dictionaries, which use XRIs to identify attributes, can have all the same general properties that Mark describes (except #5, which applies only to URLs), only they don't have to explicitly be expressed as fragments. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, April 10, 2007 5:53 PM To: Mark Wahl Cc: OpenID specs list; ID Schemas Subject: Re: in favor of allowing a fragment in a URI for metadata for anattribute type Good argument Mark, I concur. +1 -- Dick On 10-Apr-07, at 4:52 PM, Mark Wahl wrote: Section 4.3 of http://openid.net/specs/openid-attribute-types-1_0-02.html suggests that in URIs defined for attributes for OpenID AX, URI fragment specifiers should not be used. Now I'm no RDF expert, but I'm in favor of allowing fragments, and perhaps even encouraging them. I'd prefer this statement be removed from subsequent versions of the OpenID AX, in order to not dissuade other schema developers from using fragments. Here are some points for discussion on that topic, I'd be interested in hearing feedback esp. from other RDF implementors. 0. Some servers will have but a single, small, fixed schema. I'd rather those servers be able to reference and serve a single RDF file with their complete schema, instead of needing to break that schema into a bunch of little schemas. For example, suppose a server only supports FOAF. Now FOAF does not use fragments for the property definitions for its attribute types, but the attribute types defined in FOAF are not currently resolvable to an RDF document that describes those attribute types. If xmlns.com where the FOAF RDF is hosted were to implement having these attribute type URIs used in FOAF be resolvable, they would either need to - create a few dozen little RDF files that together mirror the content of foaf.rdf, or - implement a URI rule that http://xmlns.com/foaf/0.1/* returns foaf.rdf If I were redefining FOAF, I'd have its attributes be defined as fragments, so that there is only one base URI for the FOAF schema. (Also to give them RDF class definitions, see below). 1. It appears to be current practice for RDF representations of metadata for attributes in Higgins to use fragments. In OWL-based systems, the RDF object at the base URI of the document is an OWL Ontology. In Higgins, which uses OWL, the object at the base URI is an OWL Ontology that 'imports' the Higgins Ontology. The RDF file for an attribute contains an OWL Class for the attribute named by a fragment,e.g., #Firstname, and several related OWL properties and RDF instances in that same file that add structure to that class. 2. In our 'schemat' implementations which attempt to generate RDF for existing schemas of 'legacy'/'installed base' protocols, it is desirable to be able to have additional, named OWL classes, RDF objects, and other modelling and descriptive data definitions that are shared across multiple attributes of a single schema. For example, a schema may define its own value syntax and matching rules, and wish to share those syntaxes and matching rules across the attributes of that schema. It would be desirable if there could be a single RDF file which contains the attribute type metadata, the syntax definition and matching rule definition, rather than needing to have the attribute type metadata in a set of files that are separate from the syntax definitions and matching rule definitions, or are duplicated in those files. 3. I find that in our implementation 'schemat' of identity metaschema attribute metadata retrieval that is a definite performance gain if all the schema elements for a particular schema can be retrieved in a single HTTP GET. It is likely that an implementation interested in an attribute Firstname of a particular schema would also be seeing a few other attributes Lastname, Middlename etc of the same schema, and it would be good if a GET that retrieves the data for Firstname also gives the implementation the rest of the schema so that it does not need to keep going back and GETing for each attribute type. 4. Requiring that each be in a separate document would likely lead to duplication of metadata, particularly Dublin Core metadata that describes the schema as a whole. I feel it would be better if the RDF object at the base URI has the Dublin Core metadata for the schema as a whole, and that the Attribute Type Metadata is a class named by a fragment below that base URI. 5. (appeal to authority) http://www.w3.org/DesignIssues/Fragment.html This means that
RE: Updated normalization section to match the upcoming XRI Syntax2.1.
Kevin Turner wrote: Sorry it took me a few months to notice this, but xri://$dns? No. I'm referring here to spec rev 274, the diff for which is attached. Can we roll that patch back, please? I'm not even sure where you're getting an XRI Syntax 2.1 reference from, there's not so much as a working draft of it published on the technical committee's page at OASIS. Thanks, =keturn Kevin, At the time David and I discussed that change I thought the first XRI Syntax 2.1 WD would be published shortly. Now it's clear it won't be out until after the f2f meeting of the XRI TC at the OASIS Symposium week after next. I agree it should not be in there until XRI Syntax 2.1 goes into public review, which is likely to be late May or early June. BTW, in the stage before Working Drafts, the TC publishes issues/proposals on its wiki. You can see the full index of issues/proposals for XRI Syntax 2.1, XRI Resolution 2.0 Working Draft 11, and XRI $ Dictionary 2.0 on the TC wiki home page at: http://wiki.oasis-open.org/xri The $dns syntax is covered on two pages: http://wiki.oasis-open.org/xri/XriCd02/DictionaryStructure is the listing of XRI $ Dictionary entries. http://wiki.oasis-open.org/xri/XriCd02/GlobalXrefs has the proposed $dns, $ip, and $(http://*) and $(https://*) resolution rules. We'd love to get feedback from you or anyone in the OpenID community if you have time to look them over. OTOH, I fully understand if you want to wait until the Working Drafts are out. I'll be sure to send a notice to the list. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Moving AX Forward (WAS RE: SREG namespace URI rollback)
+1 to defining attribute identifier URIs/XRIs in the Identity Commons ID Schemas project. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, April 04, 2007 1:16 PM To: Johnny Bufu Cc: OpenID specs list Subject: RE: Moving AX Forward (WAS RE: SREG namespace URI rollback) Johnny, I see a lot of, at least my initial confusion, coming from there being multiple documents. This is why I urge merging the transport and metadata since the reality is they currently are only being used with each other. As the metadata document doesn't actually define a new format, rather references existing formats, I am unsure why it cannot just be a section in the transport document. It is understood that you must use the metadata format for the schema URLs in the transport, so the two documents really are coupled to begin with. I agree that you need to bootstrap a set of attributes for people using AX. As I have done so in the past, I'd encourage this work happen within the ID Schemas project (http://idschemas.idcommons.net/) versus defining First Name yet again for openid.net. I have no problem with the spec listing a set of schema URLs, I just strongly feel that anything non-OpenID specific should be hosted and defined elsewhere since so many people have already done it. I do understand the need for the schema URL hosting the metadata document, which is why I am advocating this work be done as part of the ID Schemas project to provide this flexibility. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 12:39 PM To: Recordon, David Cc: Dick Hardt; OpenID specs list Subject: Re: Moving AX Forward (WAS RE: SREG namespace URI rollback) On 4-Apr-07, at 12:18 PM, Recordon, David wrote: One thing that I do think would be worthwhile in smoothing more of this SREG/AX confusion would be adding SREG support to Sxip's OpenID libraries. This is on the todo list, and judging by the interest showed by some contributors could happen any day now. Any thoughts on spec consolidation I think I'd propose the following: - Remove http://openid.net/specs/openid-attribute- types-1_0-02.html (I do not believe OpenID should define its own schema elements for things like First Name which are not specific to OpenID, defining a URL for an OpenID enabled URL for example I think would be fine on OpenID.net) I understand that point of view and we were looking into determining what would be the best place where this spec could live. However, since the AX's adoption will depend (at least in the beginning, before the metadata and automatic acquisition mechanisms are finalized) on the participants using the same names for the attributes they transfer. From this point of view, I believe AX could use openid.net's recommendation (if endorsement is too much) to use a set of names / URIs for the most commonly transfered attributes. (Kind of like what made SREG successful -- having the spec provide / something/ for a jump-start). - Merge http://openid.net/specs/identity-attribute- metadata-1_0-01.html into http://openid.net/specs/openid-attribute-exchange-1_0-04.html. I don't think we should merge the AX core with the metadata description document. The first one describes the transport layer for attributes and is reasonably close to a final v1, while the metadata is far from being final (no concrete options identified that would drive to consensus) and its progress is rather slow. and seperating policy from technology? Not sure what you mean by this. Johnny ___ 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: Modularizing Auth 2.0 Discovery
I've always been supportive of breaking out OpenID Discovery into a separate spec. I wouldn't break it out into separate specs, however, because discovery for any OpenID identifier has have much more in common than they have different. For example, they all need to explain the relationship of the identifier being resolve to an XRDS document and the metadata needed to access other OpenID services. So I'm make the OpenID Discovery spec modular rather than breaking it out into separate specs. It also very nicely fits the OpenID layer model, i.e., one specification (one might argue the foundational spec) for OpenID Discovery -- the layer that maps an OpenID identifier to the metadata needed to access an OpenID service -- followed by a specification for OpenID Authentication, and then other specs from there. In fact, I'm excited enough about this approach that I'll volunteer to be one of the editors for OpenID Discovery. I can specifically handle coordination between the OpenID Discovery spec and the XRDS definitions in the XRI Resolution spec at OASIS. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, February 28, 2007 11:26 AM To: Martin Atkins; specs@openid.net Subject: RE: Modularizing Auth 2.0 Discovery +1, I'm fully in support of this and actually have been wanting to do so for quite a number of weeks now! --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 10:44 AM To: specs@openid.net Subject: Modularizing Auth 2.0 Discovery Recently there has been talk about using alternative identifiers for OpenID, such as email addresses and Jabber Identifiers. This has made it obvious that the OpenID Authentication protocol doesn't care in the slightest what the identifier is as long as service discovery can be performed on it somehow. Currently the Authentication 2.0 specification has language in various places that constrains it to URIs with the schemes http, https and xri. For example, under Terminology the following definition is given for Identifier: An Identifier is either a http or https URI, (commonly referred to as a URL within this document), or an XRI [XRI_Syntax_2.0]. This document defines various kinds of Identifiers, designed for use in different contexts. My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It would just state that an identifier is a URI. Later in the spec, where currently it enumerates a bunch of ways to do discovery, it'd just say do discovery on the URI using an appropriate protocol. (or, indeed, words to that effect.) It would also nominate a standard XRDS service type URI to use during Yadis discovery. Then we'd publish in parallel the following two ancillary specifications: * OpenID Discovery for HTTP and HTTPS URIs * OpenID Discovery for XRI URIs. Later, the OpenID community or a third party could publish a specification OpenID Discovery for Email Addresses, but I don't think we're really ready to go there right now. The discovery protocols don't necessarily need to be XRDS-based, but if they are they would presumably reference the standard service type URI from the Auth spec so that future Auth versions can change this without needing to re-publish the discovery specs. This has the following benefits: * It gives others a clear, spec-approved mechanism to bolt-on support for additional URI schemes. * It allows the Authentication specification to evolve separately from the various discovery specifications, which are unlikely to need to change very much from version-to-version. * It formalizes the separation between discovery and authentication, giving library authors a clear plug-in point if they wish to support modular discovery. Presumably the OpenID Auth 2.0 spec would still retain a reference to the HTTP and HTTPS discovery spec purely so that it can say that RPs MUST support it regardless of what else they support. - All ancillary discovery specifications must, at minimum, define: * A pattern for recognizing and canonicalizing their own identifiers. (For example, the XRI one would include a provision for checking for an identifier which starts with a global context symbol, etc.) * A mechanism for returning the following information: - Either: (traditional identity case) * Canonical Claimed identifier (an i-number, for example) * User-supplied Display identifier (an i-name, for example) * OP endpoint URL * OP-local identifier (i.e. openid:Delegate as was) - Or: (directed identity case) * OP endpoint URL * Canonical OP identifier (for use in confirmation messages) (And, of course, not all discovery mechanisms would necessarily support directed identity.) ___ specs
RE: Modularizing Auth 2.0 Discovery
Drummond Reed wrote: Under this approach, discovery all identifiers (URLs, XRI i-names/i-numbers, email addresses, phone numbers, etc.) would be handled by OpenID Discovery. Martin Atkins wrote: I disagree that a single spec can contain discovery rules for all conceivable discovery types without becoming ridiculously big. The discovery rules in the current spec for just handling HTTP/HTTPS and XRI discovery are already big enough. I'm not proposing a single spec for all discovery rules for all types of identifiers forever. I am proposing a spec that: 1) Sets out the general framework and requirements for OpenID Discovery because there is a lot that discovery for any identifier will have in common (for example, the general rules around XRDS usage). 2) Include sections for the specific identifier types that are already well-known and implemented -- URLs and XRIs. 3) Specifies how it extensions can be written for other identifiers, such as email addresses, phone numbers, SIP endpoints, etc. However, I clearly have a bias for lots of small specs over one large spec, and clearly your bias is the opposite. :) Why do you say that? I've been doing specs for a decade now both inside and outside of SDOs, and I don't think anyone I've ever worked with would say, Drummond likes great big bulky specifications. In fact, they would tell you I absolutely hate them. David and I did a joint paper/presentation on OpenID at the last's fall ACM conference and we specifically touted OpenID's modular lightweight specification approach. But more than anything I'm a big believe Einstein's as simple as possible but no simpler. In this case, I believe the OpenID framework should have a clear, cohesive discovery layer, and to do that, it should be anchored in an OpenID Discovery spec. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Wiki page: Attempting to document the Email Address as OpenIddebate.
David, Great wiki page -- this is the kind of resource that really helps work through issues like this. On the issue itself, I need more time to think it through. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling Sent: Saturday, February 10, 2007 12:54 PM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Wiki page: Attempting to document the Email Address as OpenIddebate. Hi List, In light of my recent extension proposal to map Email Addresses to OpenId URLs, I have setup a wiki page on openid.net that attempts to capture all the pro/cons/issues that have been shared in the debate over whether this is a good idea or not. http://openid.net/wiki/index.php?title=Debating_Emails_as_OpenIds I have tried as best I can to present a non-partisan wiki page that simply details the pros/cons of each argument. Basically, the point is to document all sides of the debate, and *not* to endorse one side or the other. That said, I'm sure some of my bias is present in the initial wording, so please feel free to suggest changes to my wording, or make them yourself. In addition, please add additional arguments and rebuttals as you see fit. The page is not nearly exhaustive (I plan to add some arguments in favor + rebuttals tomorrow when I have time). Thanks! David ___ 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: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?
Bob, From the report you show, the Yadis diagnostic is doing the correct resolution call to the xri.net HXRI proxy resolver. So it's sites that have the pre-Yadis RP libraries that won't yet work with HXRIs (or with any other Yadis-enable URL for that matter). Those libraries are only looking for the HTML link elements (I think). And I completely agree that an XRI in any format - raw i-name, with an xri:// scheme prefix, or with an HXRIs proxy resolver prefix like http://xri.net http://xri.net/ - all need to be interchangeable. You're right that this will require a slight fix at the i-brokers. =Drummond _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Wyman Sent: Wednesday, January 03, 2007 11:38 PM To: Drummond Reed Cc: Recordon, David; openid-general; specs@openid.net Subject: Re: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID? Drummond, Thanks for the detailed response. BTW: Below, you'll see what is happening when I use the Yadis diagnostic on the HXRI. I believe that users will, in fact, expect XRI's, i-names, and HXRI's to be interchangeable. I'm using 2idi.com, so I guess I have to wait for them to put in the fix? Also, I find it a bit odd that the Yadis diagnostic reports a pass for OpenID... Apparently, the metric for passing is pretty forgiving. bob wyman http://www.openidenabled.com/resources/yadis-test/yadis-detect?url=http%3A%2 F%2Fxri.net%2F%3Dbobwyman http://www.openidenabled.com/resources/yadis-test/yadis-detect?url=http%3A% 2F%2Fxri.net%2F%3Dbobwymannegotiation=on negotiation=on Results for http://xri.net/=bobwyman: * I fetched http://xri.net/=bobwyman, asking for content type application/xrds+xml * The document's content type is application/xrds+xml;trust=none. That is the XRDS content type. * There was no YADIS HTTP header. * I got a document. It is 916 bytes long and begins '?xml version=1.0 encoding=UTF-8?\nXRDS ref=xri://=bobwyman x' * I parsed an XRDS document. * I found a service, but it's not a type I recognize. It's a service at http://2idi.com/contact/ * I found a service, but it's not a type I recognize. It's a xri://+i-service*(+contact)*($v*1.0) service at http://2idi.com/contact/ * I found a service: OpenID at https://2idi.com/openid/ with delegate None * I found a service: OpenID at http://2idi.com/openid/ with delegate None * XRDS: Passed Your YADIS URL leads to an XRDS document. Your YADIS URL is http://xri.net/=bobwyman * OpenID: Passed Your YADIS URL leads to at least one OpenID service. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?
You're right, David -- the only real effect in the spec should be that an HXRI is recognized as being an XRI (and not a URL) from the standpoint of what the RP should do once it gets back the XRDS document, i.e., the RP MUST use the CanonicalID i-number and not the original HXRI. That would solve the issue Johnny brought up, and also properly support the use of multiple i-name (or HXRI) synonyms for the same i-number. =Drummond -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 03, 2007 11:34 PM To: Drummond Reed; Bob Wyman; openid-general; specs@openid.net Subject: RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID? Therefore it seems to me the best thing to do would be to have OpenID libraries recognize an HXRI (from the http://xri.* pattern) as a form of an XRI, drop the HXRI proxy resolver prefix, and proceed with it as an XRI so the user gets the i-name/i-number synonym benefits they expect. I'd agree from a usability standpoint that would be the best recommendation. The only thing that would be a bit hard to explain is that the library could still use http://xri.net as a proxy resolver. So the potentially confusing steps would be: 1) User enters http://xri.net/=bobwyman 2) RP sees prefix http://xri.net/=; and then extracts =bobwyman 3) RP constructs Yadis fetch on http://xri.net/=bobwyman for proxy resolution of the i-name =bobwyman --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 03, 2007 11:26 PM To: Recordon, David; 'Bob Wyman'; 'openid-general'; specs@openid.net Subject: RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID? Bob, it's a great question, and David's correct as far as he goes, and so is Johnny. However I suspect that the behaviour you're experiencing is due to older OpenID libraries being used by the RP site at which you're experiencing this behaviour. Here's why: if you entered your i-name =bobwyman in URL format (we call this an HXRI -- HTTP XRI) as http://xri.net/=bobwyman, then Johnny is correct that by both the 1.1 and (pending) 2.0 specs, this would be considered a URL, and Yadis resolution should proceed on the URL. However Yadis resolution means the RP library should first do an HTTP GET on the URL with a content type of application/xrds+xml. Such a request to an XRI proxy resolution server (which is what http://xri.net is functioning as) should return you the XRDS document for the XRI =bobwyman, exactly as Yadis would for any other URL that has its own XRDS document. In which case everything should work fine (except the issue of http://xri.net/=bobwyman now being the Claimed Identifier, see below). Because that's not happening, the RP library at the site you're testing must not be doing Yadis resolution, or at least not requesting an XRDS document type first. Instead it's just doing a plain http GET with no content type, in which case the HXRI proxy resolver is returning a redirect to the default service endpoint in the XRDS document per the XRI Resolution spec. Since for most i-names, the default service endpoint is the registrant's contact page, at least one i-broker, 1id.com, has cleverly got around this non-Yadis-compliant behaviour by adding the necessary OpenID link elements to the HTML of the contact page. (Victor Grey at 2idi told me today that he plans to implement the same workaround.) While this is a smart workaround, it shouldn't be necessary if the library just does Yadis resolution in the correct order on the HXRI. However all of this still leaves the open issue that Johnny raised, namely that the current draft OpenID Authentication 2.0 spec treats =bobwyman and http://xri.net/=bobwyman as separate identifiers. Ironically, in XRI Syntax 2.1 the XRI TC is formalizing HXRI syntax (it was originally part of XRI Resolution 2.0 Working Draft 10, but we need to make it a formal part of XRI Syntax), and we are making it very explicit that from the standpoint of equivalence, the proxy resolver prefix of any HXRI is NOT part of the XRI. In other words, the following two identifier... http://xri.net/=bobwyman =bobwyman ...are equivalent XRIs because the former is really just the HXRI proxy resolver prefix http://xri.net; plus the absolute XRI =bobwyman. Therefore it seems to me the best thing to do would be to have OpenID libraries recognize an HXRI (from the http://xri.* pattern) as a form of an XRI, drop the HXRI proxy resolver prefix, and proceed with it as an XRI so the user gets the i-name/i-number synonym benefits they expect. Johnny, David, Josh: do you agree? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, January 03, 2007 8:55 PM To: Bob Wyman; openid-general; specs@openid.net Subject: Re: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwymananOpenID? My guess is that when
RE: Key Discovery In DTP Draft 3
Just FYI, the xmldsig KeyInfo element is already part of the XRD schema because the XRI Resolution spec uses it in the SAML form of trusted XRI resolution. And either the SAML form or the HTTPS form of XRI trusted res can give you the security characteristics in the Key Discovery spec. That said, there can be advantages to managing the cert via an independent service. So I'm not coming down on either side (yet ;-) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, January 04, 2007 10:07 PM To: Carl Howells; Grant Monroe Cc: specs@openid.net Subject: Key Discovery In DTP Draft 3 Hey guys, Was looking at http://openid.net/specs/openid-service-key-discovery-1_0-01.html tonight and curious why the decision was made to define the PublicKey / element which contains a link to the RSA key or X.509 certificate versus embedding the key in the XRDS file? From the research I've done tonight, it looks like the W3C in 2002 described how to do this as part of xmldsig. Seems like we can just use the KeyInfo element. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo They've also then recently put out a note describing the changes to that document to match XML in 2006. http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/ Is there something that I'm missing from the design standpoint as to why this wasn't done? If anything, it seems like it would reduce a fetch if the key was in the XRDS file itself. --David ___ 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: Key Discovery In DTP Draft 3
That could work. Very XDI RDF-like approach, i.e., the URL/XRI being resolved is the Subject, the URL/XRI value of the Type element is the RDF predicate, and the value of the data sharing:KeyInfo element is the RDF object (in this case a literal). =Drummond -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Thursday, January 04, 2007 10:35 PM To: Drummond Reed; Carl Howells; Grant Monroe Cc: specs@openid.net Subject: RE: Key Discovery In DTP Draft 3 Oooh, interesting... So looking at working draft 10 http://www.oasis-open.org/committees/download.php/17293 it seems that 3.2.5 is most relevant in that it describes xrd:XRD/xrd:Service/ds:KeyInfo which seems to be where in the schema the key would want to sit. The only thing is that 3.2.5 is talking about having the key present to verify a signature on the XRD file itself, though in this case it may not actually be signed. What I was toying with was something along the lines of: Service Typehttp://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo/ Type ds:KeyInfo ... /ds:KeyInfo /Service Thus it makes it easy for existing Yadis libraries to pick the key out by the Type element. --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Thursday, January 04, 2007 10:23 PM To: Recordon, David; 'Carl Howells'; 'Grant Monroe' Cc: specs@openid.net Subject: RE: Key Discovery In DTP Draft 3 Just FYI, the xmldsig KeyInfo element is already part of the XRD schema because the XRI Resolution spec uses it in the SAML form of trusted XRI resolution. And either the SAML form or the HTTPS form of XRI trusted res can give you the security characteristics in the Key Discovery spec. That said, there can be advantages to managing the cert via an independent service. So I'm not coming down on either side (yet ;-) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, January 04, 2007 10:07 PM To: Carl Howells; Grant Monroe Cc: specs@openid.net Subject: Key Discovery In DTP Draft 3 Hey guys, Was looking at http://openid.net/specs/openid-service-key-discovery-1_0-01.html tonight and curious why the decision was made to define the PublicKey / element which contains a link to the RSA key or X.509 certificate versus embedding the key in the XRDS file? From the research I've done tonight, it looks like the W3C in 2002 described how to do this as part of xmldsig. Seems like we can just use the KeyInfo element. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo They've also then recently put out a note describing the changes to that document to match XML in 2006. http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/ Is there something that I'm missing from the design standpoint as to why this wasn't done? If anything, it seems like it would reduce a fetch if the key was in the XRDS file itself. --David ___ 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: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?
Bob, it's a great question, and David's correct as far as he goes, and so is Johnny. However I suspect that the behaviour you're experiencing is due to older OpenID libraries being used by the RP site at which you're experiencing this behaviour. Here's why: if you entered your i-name =bobwyman in URL format (we call this an HXRI -- HTTP XRI) as http://xri.net/=bobwyman, then Johnny is correct that by both the 1.1 and (pending) 2.0 specs, this would be considered a URL, and Yadis resolution should proceed on the URL. However Yadis resolution means the RP library should first do an HTTP GET on the URL with a content type of application/xrds+xml. Such a request to an XRI proxy resolution server (which is what http://xri.net is functioning as) should return you the XRDS document for the XRI =bobwyman, exactly as Yadis would for any other URL that has its own XRDS document. In which case everything should work fine (except the issue of http://xri.net/=bobwyman now being the Claimed Identifier, see below). Because that's not happening, the RP library at the site you're testing must not be doing Yadis resolution, or at least not requesting an XRDS document type first. Instead it's just doing a plain http GET with no content type, in which case the HXRI proxy resolver is returning a redirect to the default service endpoint in the XRDS document per the XRI Resolution spec. Since for most i-names, the default service endpoint is the registrant's contact page, at least one i-broker, 1id.com, has cleverly got around this non-Yadis-compliant behaviour by adding the necessary OpenID link elements to the HTML of the contact page. (Victor Grey at 2idi told me today that he plans to implement the same workaround.) While this is a smart workaround, it shouldn't be necessary if the library just does Yadis resolution in the correct order on the HXRI. However all of this still leaves the open issue that Johnny raised, namely that the current draft OpenID Authentication 2.0 spec treats =bobwyman and http://xri.net/=bobwyman as separate identifiers. Ironically, in XRI Syntax 2.1 the XRI TC is formalizing HXRI syntax (it was originally part of XRI Resolution 2.0 Working Draft 10, but we need to make it a formal part of XRI Syntax), and we are making it very explicit that from the standpoint of equivalence, the proxy resolver prefix of any HXRI is NOT part of the XRI. In other words, the following two identifier... http://xri.net/=bobwyman =bobwyman ...are equivalent XRIs because the former is really just the HXRI proxy resolver prefix http://xri.net; plus the absolute XRI =bobwyman. Therefore it seems to me the best thing to do would be to have OpenID libraries recognize an HXRI (from the http://xri.* pattern) as a form of an XRI, drop the HXRI proxy resolver prefix, and proceed with it as an XRI so the user gets the i-name/i-number synonym benefits they expect. Johnny, David, Josh: do you agree? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, January 03, 2007 8:55 PM To: Bob Wyman; openid-general; specs@openid.net Subject: Re: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwymananOpenID? My guess is that when a normal HTTP fetch is performed against http://xri.net/=bobwyman, the proxy resolver expects you to be in a browser and thus issues a 302 Redirect to your contact page. One option is if the iBrokers (is it iBroker or i-broker?) included Yadis on each contact page. This would mean the OpenID Relying Party would fetch http://xri.net/=bobwyman, be redirected to http://2idi.com/contact/=bobwyman, and then have that URL to perform discovery. The problem this presents is that the Relying Party follows redirects and canonicalizes the final URL as the Claimed Identifier. This thus means you'd no longer be making a claim about http://xri.net/=bobwyman, but rather that you own http://2idi.com/contact/=bobwyman. Thus if you change iBrokers, this assertion would no longer remain valid. It also removes the protection the iNumber (and CanonicalID tag) adds to the XRI Resolution process since i-names can be reassigned. I'm unsure if there is some trickery that could be done in the Yadis discovery document to resolve this, though really what I think would end up is you would enter http://xri.net/=bobwyman to start the discovery process, but then end up making an assertion about =bobwyman and not the URL version of it. Someone correct me here if my logic is wrong. --David From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Wyman Sent: Wednesday, January 03, 2007 8:44 PM To: openid-general Subject: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman anOpenID? My apologies if this is a really dumb question... Why is it that I can do OpenID authentication with either of =bobwyman or xri://=bobwyman but, according to the OpenIDEnabled checkup
RE: Questions on Protocol
Welcome, James. I have a special interest in this topic due to my work on XDI (XRI Data Interchange) at OASIS. I'm happy to help figure out how it can be applied here. +1 to Dick's suggestion to just keep the posts modular, i.e., short on-topic threads that can be discussed individually. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, January 02, 2007 1:06 PM To: McGovern, James F (HTSC, IT) Cc: specs@openid.net Subject: Re: Questions on Protocol Hi James These look like good discussion topics for the specs list. A separate post clarifying each notion would be a great starting point. -- Dick On 2-Jan-07, at 8:57 AM, McGovern, James F ((HTSC, IT)) wrote: Johannes invited me to lead the development of the specification for including relationships and authorization as part of OpenID. I have the following questions: 1. Would it be too distracting to have the conversation occur on this listserv or should the admin establish another one? 2. I would also like to get a dialog going around how OpenID would need to work in order to support notions such as Identity propagation, integration into BPM and ECM platforms and support for Identity Based Encryption ** *** 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: [OpenID] OpenID Assertion Quality Extension - Draft
Avery, Paul's the one to weigh in on this option - he wrote (and lived) the book on SAML AuthN Context. But I do like the looks of what you proposed - seems very elegant. =Drummond _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Avery Glasser Sent: Thursday, November 30, 2006 2:22 PM To: George Fletcher Cc: specs@openid.net; [EMAIL PROTECTED] Subject: Re: [OpenID] OpenID Assertion Quality Extension - Draft Just to weigh in here... Paul Madsen wrote: Hi George, for your use case below, why would not the RP just ask for the user to be up-authenticated at the desired higher level when necessary? So in the draft... how does the RP ask for the user to be up-authenticated? The authentication request parameters do not in any way indicate a previous authentication, and the extension parameters also don't include any way to indicate a previous authentication. That is what I really meant by the authentications being standalone. The RP may relate the two authentications in some way because it requested both. Maybe that's good enough. Basically, you would require the second method with a max_age of 0 - which, assuming the RP honors the request, would tell the RP to re-authenticate the user with the requested method. Are you asking whether the RP should be allowed to ask the user to re-present their URI in order for this to happen? And thereby effectively treating each event as disconnected/standalone? Ideally, the user would not be able to change their URI when being re-challenged based on max_auth_age but I guess the RP should make sure to code for that edge case. Agreed - it's the RPs choice. Wrt combinations, I know from experience that the alternative to allowing for RPs to specify combinations is a combinatorial explosion in the number of mechanism identifiers. I agree that the combinations can explode... but they are also useful. For example to hack my account you need both my password and my hardotp. That's two secrets that need to be determined for my account to be compromised. (Not that this doesn't stop phishers). Actually, this could be pretty simple to implement: Replace openid.aqe.preferred_auth_mode with the following: openid.aqe.auth_factor1 Optional: The method of authentication the RP would like the OP to perform, or in the case of a multi-factor authentication, the first method that the RP would like the OP to perform. The mode should match one of the advertised values in the XRDS. If this is not specified, then any authentication method is acceptable. Value: Comma-delimited list of none, password, pin, fingerbio, handbio, hardotp, irisbio, otherbio, smartcard, softotp, voicebio Note: The OP should attempt to authenticate the user with the most secure mode requested. For example, if the OP has determined that their voicebio method is stronger than their password method and the RP requests either voicebio or password, the OP should strive to authenticate the user by voicebio when possible. If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against. OPs should note that authenticating a user by a non-preferred method may result in an RP denying access. openid.aqe.auth_factor2 Optional: In the case of a multi-factor authentication, the second method that the RP would like the OP to perform. The mode should match one of the advertised values in the XRDS. If this is not specified, then any authentication method is acceptable. If this is not specified, it is assumed that the RP is requesting only a single factor for authentication. The OP will not use the same method for this factor as was used in any previous factors. For example, if the first factor is a password, the second factor cannot also be a password. Value: Comma-delimited list of none, password, pin, fingerbio, handbio, hardotp, irisbio, otherbio, smartcard, softotp, voicebio Note: The OP should attempt to authenticate the user with the most secure mode requested. For example, if the OP has determined that their voicebio method is stronger than their password method and the RP requests either voicebio or password, the OP should strive to authenticate the user by voicebio when possible. If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against. OPs should note that authenticating a user by a non-preferred method may result in an RP denying access. openid.aqe.auth_factor3 ... you can figure how it would continue. There are very few use cases that would use more than two factors. So, in this case, if you want the user to authenticate with two factors, first with a password and second with a securID or voice biometric print... openid.aqe.auth_factor1 = password openid.aqe.auth_factor2 = hardotp, voicebio conversely, if you want two factors, which could
RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Watkins Sent: Wednesday, November 08, 2006 4:21 PM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers Recordon, David wrote: Involving DNS seems to make this too complex. If we're going to involve DNS, we might as well re-architect Yadis to use it as yet another discovery option. Yes, the TXT proposal seems complex. I prefer Phillip's second suggestion, but I think something more unique would be advisable, e.g. http://openid.example.com/openid/user so that organizations can more easily separate the OpenID IdP systems (hostname openid.MAILDOMAIN, web path /openid/) from any regular http/https offerings. It would be nice (see my 'concerns about each user having a unique URL' thread in the general openid list) if this could handle empty usernames, e.g. if users could claim an identifier like @example.com to identify the IdP but let the IdP determine the user's identifier. Peter, as I mentioned in my reply on the General list, this is how the directed identity feature in OpenID Authentication 2.0 works. That was David's original suggestion as I remember -- have OpenID RPs treat an email address as simply an IdP name and execute the protocol from there. Since the XRI TC is now working on specifying the email form of an XRI (called an MXRI -- mailto XRI), this could work for both ordinary email addresses and MXRI addresses. But that's only if we decide that using an email address as an OpenID identifier makes sense, or if it just adds a new layer of confusion (as others have noted). =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Authentication Authority (was RE: IdP vs OP (WAS: RE: Editors Conference Call))
Eve, Welcome, and thanks for delurking ;-) I'm fascinated by your suggestion that the SAML vocabulary includes the term authentication authority. I'd vote for the OpenID Authentication 2.0 specification (and the community at large) to adopt that term in a heartbeat because: a) I've many times thought that authentication authority was PRECISELY the role that the IdP/OP played in OpenID Authentication. b) I'm all for consistency with the SAML glossary because I know it was intended to be specification-neutral and I'm a big supporter of harmonizing vocabularies in a problem space (that's why we spent so long on the XRI glossary in the identifier problem space -- see appendix C of http://www.oasis-open.org/committees/download.php/15377). c) It allows us to step around all the semantic issues around whether an OpenID IdP is really providing an identity or not (and also whether OpenID is using classic identity federation or not.) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eve L. Maler Sent: Tuesday, November 07, 2006 8:16 AM To: specs@openid.net Subject: Re: IdP vs OP (WAS: RE: Editors Conference Call) Delurking for the first time on this list: :-) Drummond and I are on the same page about many things, but John is right that SAML is agnostic as to the strength/significance of the service being provided and so the two cases are much more similar than different. On balance I prefer identity provider because it's intuitive in an English sense, it's used in several technology contexts (not just SAML and OpenID), and it avoids a terminological branding that would otherwise seem to suggest a conceptual divergence that doesn't -- to my mind -- exist. (By the way, there's another term SAML defines that seems to fit the bill of what Drummond is going for here: authentication authority. This is not quite synonymous with identity provider in SAML-land, but it's close -- much the way that relying party and service provider are often close to the same thing. I'm not seriously advocating using it -- just noting that the same software component in an actual deployment can be seen in various lights and have multiple names (roles!).) FWIW, Eve John Kemp wrote: Hi Drummond, Drummond Reed wrote: So why, indeed, is there so much interest in OpenID? I believe it's because of the trust model. To the best of my knowledge, it is radically different than the trust model assumed by the majority of use cases which led to SAML and the Liberty Alliance specs. As Eve Maler of Sun puts it, OpenID supports promiscuous federation -- RPs and OPs that don't know anything at all about each other. At http://www.openidp.org you'll find a promiscuous SAML IdP. While I agree with you that OpenID has been focused on this use-case, with an eye to the use-cases satisfied by SAML, I'd say that SAML has been developed with federated use-cases, but also with an eye to promiscuity. But to put it another way, the trust model used with SAML is out-of-scope for development of the SSO protocol itself. Just like it is for OpenID. And it doesn't stop there. OpenID also supports OPs that ***have zero control over the user's OpenID identifier***. The OP simply provides a service for authenticating that a user has control of the OpenID identifier about which the OP is being queried. And how does one authenticate that the user has control over an identifier? Is it not by having the OpenID IdP having some secret shared with the user - maybe a password, say? A SAML IdP also authenticates that an identifier (issued by the IdP in the SAML case) is bound to a particular user. This is a big deal. In fact, the closer you get to it, the bigger it is. As a result, even though an OP seems to fit the SAML definition of an IdP -- and many technical folks will be very comfortable treating the two as synonymous -- getting the semantics right to stress who really is in control of the identity ***right down to the identifier*** is very important. I don't think we need to worry about fitting the SAML glossary definition of an IdP, but rather we should focus on making an OpenID glossary definition that makes sense for what OpenID is doing. Whatsmore, I don't think this should or will drive SAML and OpenID further apart. In factit could actually help pave the path to convergence: an OP can be defined as being a SAML IdP that provides identifier authentication services using the OpenID protocol, which may end out (3.0?) becoming a very specific set of SAML capabilities. As noted earlier, I think a SAML IdP also provides identifier authentication. I don't worry so much about convergence of these technologies (although that would be nice ;), but more about giving a converged message to users, developers, and purchasers of these technologies. Regards, - John =Drummond -Original Message- From: [EMAIL
RE: OpenID.net Service Type Namespaces
My understanding is that the concern is with potential conflicts in the actual functioning of openid.net. Creating a clean DNS namespace for specs at specs.openid.net does seem like a good solution to me. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, November 07, 2006 8:09 AM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID.net Service Type Namespaces What is the concern? The argument for keeping it the current way is for consistency. The URL resolution does not need to be trusted does it? On 6-Nov-06, at 5:04 PM, Recordon, David wrote: I'm still concerned with using the openid.net/ namespace. Objections to using http://specs.openid.net/authentication/2.0/signon? We don't need to change this in legacy stuff, just for 2.0 moving forward. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Saturday, October 21, 2006 7:34 PM To: Granqvist, Hans Cc: Recordon, David; specs@openid.net Subject: Re: OpenID.net Service Type Namespaces I am very supportive of an HTTP GET retrieving the specification. I think there are some issues with putting the date in the URL: 1) the URL is unknown until the spec is completed. Any implementations being done during the specification then have a moving target. The URL is embedded in the Yadis document and I can see it causing some headaches for people that it is not fixed until the end. 2) the grouping is by time instead of by specification. If I want to see all versions of a specification, it is not obvious Currently we have: http://openid.net/signon/1.0 http://openid.net/signon/1.1 http://openid.net/server/2.0 http://openid.net/signon/2.0 http://openid.net/identifier_select/2.0 Given that the 1.x ones are already there, I would recommend we keep using that scheme. -- Dick On 20-Oct-06, at 3:39 PM, Granqvist, Hans wrote: It has had some voices against it, but how about considering this template (used in for example W3C xmldsig and xmlenc): http://openid.net/[year]/[month]/[project]#[type] Time-dependent (rather than version--dependent) namespaces can evolve freely and will not be tied down to specific versioning numbers. Example: http://openid.net/2006/10/authentication http://openid.net/2006/10/authentication#signon It's cool if an HTTP GET on these links returns the specification. Once a spec is finalized, the then current year/month becomes that spec's namespace. For example, xmlenc's namespace is http://www.w3.org/2001/04/xmlenc Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Friday, October 20, 2006 3:09 PM To: specs@openid.net Subject: OpenID.net Service Type Namespaces Right now we have things like http://openid.net/signon/1.1, http://openid.net/sreg/1.0, etc. This doesn't really seem to scale, populating the main http://openid.net namespace. Could we do something like http://specs.openid.net/authentication/2.0/signon or http://specs.openid.net/authentication/2.0/identifier_select as well as then http://specs.openid.net/sreg/1.0? This would give all the specs their own namespaces, as well as make it so we can do smart redirection from each of these type urls to the correct anchor in the individual spec. --David ___ 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Making return_to Optional
David, in the message below, I assume you meant to say return_to is NOW an optional parameter... instead of return_to is NOT an optional parameter That's the only way I can make sense of it. Am I right? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Monday, November 06, 2006 11:10 AM To: specs@openid.net Subject: Making return_to Optional From the call last week and the proposal at http://openid.net/pipermail/specs/2006-October/000430.html, return_to is not an optional parameter in the authentication request. The idea being that a RP not sending it signals the IdP to not redirect the user back; rather an extension will be doing something useful. I've checked in this change, though would like it reviewed since I am not completely happy with all the wording. http://openid.net/svn/comp.php?repname=specificationspath=compare%5B%5 [EMAIL PROTECTED]compare [EMAIL PROTECTED]ma nualorder=1 Thanks, --David ___ 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: IdP vs OP (WAS: RE: Editors Conference Call)
I want to clear up what I believe are two misconceptions about the proposed terminology change (both in the specs and across all the OpenID educational/marketing materials) from Identity Provider (IdP) to OpenID Provider (OP). (Note that these are my personal views and may not be shared by others on the list -- the are offered to help propel the discussion towards a community consensus.) 1) I don't personally believe there is much difference at all between identity provider (IdP) and OpenID provider (OP) -- certainly not enough to debate. We might even just agree that an OP is what SAML calls an IdP that uses the OpenID protocol for authentication. That's not at all the reason why I support the terminology change. The real reason... 2) ...is that in the context of user-centric identity, I have always felt that the term identity provider -- though I fully understand that it goes back to the start of SAML -- is at least inappropriate and perhaps even downright misleading. Why? It's because in a user-centric identity, the OP is fundamentally NOT (that enough stars for you? ;-) the provider of anyone's identity. This might look like a little thing, but on such little things entire worldviews rest. Let me elaborate. In the last 2 months, I've had numerous conversations with SAML proponents asking me, Why is there so much interest in OpenID? It's just reinventing SAML without a lot of the complexity. And each time I admit that, to the best of my knowledge, this is largely true. So why, indeed, is there so much interest in OpenID? I believe it's because of the trust model. To the best of my knowledge, it is radically different than the trust model assumed by the majority of use cases which led to SAML and the Liberty Alliance specs. As Eve Maler of Sun puts it, OpenID supports promiscuous federation -- RPs and OPs that don't know anything at all about each other. And it doesn't stop there. OpenID also supports OPs that ***have zero control over the user's OpenID identifier***. The OP simply provides a service for authenticating that a user has control of the OpenID identifier about which the OP is being queried. This is a big deal. In fact, the closer you get to it, the bigger it is. As a result, even though an OP seems to fit the SAML definition of an IdP -- and many technical folks will be very comfortable treating the two as synonymous -- getting the semantics right to stress who really is in control of the identity ***right down to the identifier*** is very important. Whatsmore, I don't think this should or will drive SAML and OpenID further apart. In factit could actually help pave the path to convergence: an OP can be defined as being a SAML IdP that provides identifier authentication services using the OpenID protocol, which may end out (3.0?) becoming a very specific set of SAML capabilities. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Monday, November 06, 2006 11:46 AM To: Dick Hardt; John Kemp; Patrick Harding Cc: specs@openid.net Subject: IdP vs OP (WAS: RE: Editors Conference Call) I see both sides of this discussion. I think John is correct that the role of an OP really is not that different than that of SAML's IdP. The difference comes down to the trust model. I certainly think reputation networks will exist which rate OPs, RPs, users, etc and will ultimately be needed for a technologies with promiscuous trust models to thrive in a large scale. I guess reading more of this is making me question if renaming IdP really is the best thing to do in OpenID. I think if anything we all, as a larger community, should be working to bring OpenID and SAML closer together versus driving them further apart. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Wednesday, November 01, 2006 2:20 PM To: John Kemp Cc: specs@openid.net Subject: Re: Editors Conference Call On 1-Nov-06, at 12:28 PM, John Kemp wrote: OK. Just checking. So an IdP/OP can choose whether or not to trust a particular RP, based on some out-of-ban criteria. And an RP can choose whether or not to trust the assertions of a particular IdP/OP? OK good. Technically possible, yes for the RP to decide on an IdP/OP. Currently, there is no verified RP identity, so the IdP/OP cannot make that decision. I have not had a chance to wade into that discussion. I'd highly recommend it when you get the chance. in my queue :) I suspect the latter case will be unlikely, if OpenID is to be successful. And I do not. And that is the big driver why it should be OP instead of IdP. I think what you're trying to say is that OpenID won't depend on static trust relationships (like business contracts) between RPs and IdP/ OPs - is that right? In which case, sure, I get that. But I do think OpenID will depend on there emerging a way of some RP trusting (or not) some
RE: Yet Another Delegation Thread
+1. In this whole discussion, I have three very strong views (which the editors can take as input into their call today): 1) If RP discovery reveals an IdP-specific identifier, the RP MUST send it to the IdP because that's what the IdP needs most to serve the user. 2) If the IdP receives an IdP-specific identifier, the IdP can act on it immediately without needing to perform discovery. There is no such thing as a stale IdP-specific identifier. The IdP is either authoritative for it or it is not. 3) Because of (1) and (2), the protocol should make it clear to the IdP when the IdP is receiving an IdP-specific identifier, i.e., it should not be ambiguous to the IdP whether the identifier is the Claimed Identifier or an IdP-specific identifier. So the whole question in my mind boils down to: even if the RP discovers an IdP-specific identifier, should the RP *also* send the Claimed Identifier? I believe there is a strong case for doing so for the reasons discussed in this thread. Go for it, editors! =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, October 26, 2006 8:28 AM To: Dick Hardt Cc: Martin Atkins; specs@openid.net Subject: Re: Yet Another Delegation Thread On 10/26/06, Dick Hardt [EMAIL PROTECTED] wrote: * If the IdP-specific identifier is not checked by the relying party's discovery, the IdP MUST do discovery on every request to ensure that it's not making an assertion based on stale information. Which is probably a good idea. :-) If the IdP is sending both identifiers in a signed response, then they both should be valid. Requiring this discovery adds another (redundant) HTTP request to the authentication process, which takes time. I'd like to be able to improve the User Experience by implementing an IdP that would verify the binding occasionally, but not *every time* the user authenticates. Josh ___ 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: Yet Another Delegation Thread
Dick, the questions you raise are exactly the kinds of tradeoffs the editors need to discuss on their telecon (I agree this issue could consume an entire call). I doubt I can add anything more here, so I'll just wish you all godspeed on the call. =Drummond -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 10:07 PM To: Drummond Reed Cc: 'Recordon, David'; specs@openid.net Subject: Re: Yet Another Delegation Thread Thanks for the explanation Drummond. I think we need a con call on this topic alone ... :-) On 24-Oct-06, at 6:16 PM, Drummond Reed wrote: * But in our discussion today, Josh and David and I boiled down the fundamental problem with the single identifier on the wire solutions: as long as the RP has the ability to do the mapping between the Claimed Identifier and an IdP-specific Identifier (and there are many good reasons to allow the RP to do this mapping, including that this is how OpenID 1.1 works), Would you elaborate on those good reasons? I'd like to understand them because they are not obvious to me. then sending only one of these two identifiers on the wire to the IdP shuts down an option the IdP and/or user should have. To wit: - If only the Claimed Identifier is sent, the IdP is forced to repeat discovery if it doesn't recognize it (Josh and David and I believe the IdP should not be forced to repeat discovery - it is not required in OpenID 1.1 and should not be required in OpenID 2.0). The IdP does not do discovery in OpenID 1.1 because the IdP is not aware of the public identifier. The RP is doing it. Either the IdP is binding the two identifiers, or the RP is doing it *after* getting them back unless it preserves state. A design goal has been to move complexity to the IdP when given a choice. - If only the IdP-specific Identifier is sent, then the IdP does not have the option to assist the user with identifier selection based on the Claimed Identifier (which is required for directed identity anyway, and is one of the motivations behind this whole thread). I don't think the RP needs to even understand the IdP-specific identifier. Our conclusion was that the only way to avoid shutting down one or the other of these options is to allow (but not force) the RP to send both identifiers using two parameters, and to have the IdP return both parameters, which the RP must always verify based on its own discovery. That's the state of the state as of our discussion this afternoon. Hopefully this will be helpful input into the editor's call(s) this week. Thanks Drummond. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Yet Another Delegation Thread
First, just to make sure intentions are clear, the conversation that David and I had yesterday (because he happened to be in Seattle) and the subsequent conversation that David and Josh and I had today (because Josh had questions about what we posted) were meant only to try to better understand the issue, not take anything offline. I personally believe that the remaining 2.0 issues need to be resolved primarily via telecons because they have proved themselves too hard to work out in email (the XRI TC holds 2 hour telecons weekly almost entirely for this purpose). David and Josh and I agreed that our discussions today were all preliminary to the telecon(s) the editors have already agreed to do starting this week. For this reason I'm hesitant to write anything further on this thread. But However I'll try to answer Dick's question as succinctly as I can: * Dick's proposal defined two different identifier parameters, but sent only one or the other on the wire depending on the initial conditions at the RP. * David's writeup yesterday also proposed sending only a single identifier parameter on the wire that would fulfill both roles that Dick's two identifier parameters filled. * But in our discussion today, Josh and David and I boiled down the fundamental problem with the single identifier on the wire solutions: as long as the RP has the ability to do the mapping between the Claimed Identifier and an IdP-specific Identifier (and there are many good reasons to allow the RP to do this mapping, including that this is how OpenID 1.1 works), then sending only one of these two identifiers on the wire to the IdP shuts down an option the IdP and/or user should have. To wit: - If only the Claimed Identifier is sent, the IdP is forced to repeat discovery if it doesn't recognize it (Josh and David and I believe the IdP should not be forced to repeat discovery - it is not required in OpenID 1.1 and should not be required in OpenID 2.0). - If only the IdP-specific Identifier is sent, then the IdP does not have the option to assist the user with identifier selection based on the Claimed Identifier (which is required for directed identity anyway, and is one of the motivations behind this whole thread). Our conclusion was that the only way to avoid shutting down one or the other of these options is to allow (but not force) the RP to send both identifiers using two parameters, and to have the IdP return both parameters, which the RP must always verify based on its own discovery. That's the state of the state as of our discussion this afternoon. Hopefully this will be helpful input into the editor's call(s) this week. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, October 24, 2006 5:12 PM To: Recordon, David Cc: specs@openid.net Subject: Re: Yet Another Delegation Thread Can we have those conversations on the list so that everyone understands what the goals missed are? I'd appreciate feedback on the revised proposal I emailed out and what is missing from it. -- Dick On 24-Oct-06, at 3:45 PM, Recordon, David wrote: I honestly wasn't really putting it out as a proposal, rather describing more of the different cases involved in all of this. In any case, talking this over more with Josh and Drummond it doesn't actually accomplish all of the goals anyway. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Monday, October 23, 2006 11:04 PM To: Drummond Reed Cc: Recordon, David; specs@openid.net Subject: Re: Yet Another Delegation Thread +1 Glad to see that we have settled on one identifier parameter On 23-Oct-06, at 7:07 PM, Drummond Reed wrote: Here's another way to summarize the conclusions David and I reached in our analysis today: 1) In OpenID Authentication 1.1, if there is a difference between the identifier the user wants to assert to an RP and the identifier the IdP wants to assert for the user (lets just call them ID1 and ID2), then the mapping from ID1 to ID2 can only be handled by the RP (using the OpenID delegate feature). 2) Josh and Mart have argued that in OpenID Authentication 2.0 an IdP should also be able to handle the mapping between ID1 and ID2, and indeed in the directed identity use case, the IdP MUST handle this mapping. 3) What David and I realized today is that there are even use cases for BOTH the RP and IdP doing the mapping. In other words, even if an RP maps from ID1 to ID2 and passes ID2 to the IdP, there shouldn't be anything to prevent the IdP from mapping ID2 to ID3 and passing ID3 back to the RP (as long as the RP verifies the IdP is authoritative for ID3). Example: I log into RP using one URI#1, which maps in my XRDS document to another IdP- specific URI#2, and then when logging into my IdP it reminds me that I previously used URI#3 at this RP, so I choose URI#3. 4) Therefore, as long as the protocol
RE: XRI confusion
Dick, you are right that there are usability challenges with i-numbers and XDI.org and the i-broker community is working to address them. Although persistent identifiers are used everywhere in local systems (directories, databases, object stores, etc.), and the concept has been around at the Internet level since the late '90s in the form of URNs (http://en.wikipedia.org/wiki/Uniform_Resource_Name), the need to integrate them into a digital identity layer is only just emerging. As with each new Internet layer, there's some stuff that just has to get figured out ;-) =Drummond -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 9:26 AM To: Drummond Reed Cc: 'Recordon, David'; 'Martin Atkins'; specs@openid.net Subject: Re: XRI confusion That provides clarity on the process, thanks. If the user knows that their i-name has been changed, then when you write here: http://www.lifewiki.net/openid/ConsolidatedDelegationProposal Summary of Motivations: ... 4. Enable RPs to take advantage of XRI CanonicalDs to protect End-Users from ever having their Portable Identifier reassigned (and thus their identity taken over). ... his is just in case they don't get alerted to their i-name being changed? btw: I have no idea what my i-numbers are, and it was not clear to me that I had them when I got them. I think there are some real usability issues here, but this is likely not the place to address those. :-) -- Dick On 19-Oct-06, at 8:12 AM, Drummond Reed wrote: Exactly. An i-name being reassigned is very similar to a domain name being reassigned -- the previous owner is going to know they no longer own it. For example, if you register blame.ca, you're going to receive multiple notices from your DNS registrar that you need to renew it, and if you don't, you know it is almost certain to be reassigned. The same is true for i-name registrants. With regard to i-numbers, every registrant is notified of their i- number, and their i-broker retains a record of the i-number. Because an i- number is NEVER reassigned, if a registrant chooses not to renew an i-name, they ALWAYS have their i-number. Note that since the i-name and i-number are directly synonymous, i.e., the i-number resolves the same XRDS as the i-name, if a registrant know their i-number, they can always use it to login at any OpenID RP at which they had previously used any i-name synonym for that i-number. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, October 19, 2006 4:09 AM To: Dick Hardt; Martin Atkins Cc: specs@openid.net Subject: RE: XRI confusion How would Alice buy =foo when Bob already owns it? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 3:58 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: XRI confusion On 19-Oct-06, at 12:44 AM, Martin Atkins wrote: Dick Hardt wrote: How would a user ever learn what their CanonicalID is? The user doesn't need to know his i-number. The system discovers that for him. If there Portable Identifier (i-name) is reassigned, then they will be sent to an IdP for the new Canonical ID is, expecting credentials from the new owner. The user will never make it back to the RP, and they will have no easy way of proving they are the owner of the CanonicalID. I don't really understand this paragraph, but when the i-name is reassigned it'll cease to point at the same XRDS and will thus not point at the IdP anymore - unless the new owner also has an account with that IdP, of course. But they have a different i-number, so the IdP can distinguish them. Bob has the i-name =foo. Alice has =foo reassigned to her. Bob does not know this. Bob goes to an RP, enters =foo and gets sent somewhere he cannot authenticate since =foo resolves somewhere else. Bob does not know what to do. =foo does not resolve to his i-number any more. How does he find out what it is so that he can get a his i- name to point to it? Additionally, in the proposal, the i-name is not sent from the RP to the IdP, so how does the IdP know which i-name to address the user as? I would hope that an IdP, given that I've already established a relationship with it, can find something better to address me with than a URI. It should be calling me Martin. Perhaps, although I would like my IdP to let me know which Identifier I am going to present to the RP. -- Dick ___ 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
RE: Question: multiple IdPs?
In the directed identity case, the IdP URL or XRI you give to the RP resolves to your IdP's XRDS document. Each of your IdPs would have a different one. If they support directed identity, each would have a Service with a Type tag value of http://openid.net/identifier_select/2.0. This service endpoint would not have an OpenID:Delegate tag (or if it does the spec should be clear that it is ignored for this service type) since this service provides directed identity authentication for everyone at that IdP. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, October 17, 2006 11:25 PM To: specs@openid.net Subject: Question: multiple IdPs? I would like to use different IdPs for my vanity URL, blame.ca. In an OpenID 2.0 world, I can provide either of my IdP URLs to the RP and then select blame.ca and login. Does this work? What having two openid.server tags suffice? How would the RP know which delegate tag goes with which IdP? The spec is not silent on this. ( and yes, another argument for having one identifier so that the RP does not have to figure out anything about the delegate tag since it does not do anything with it anyway!) -- Dick ___ 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: Consolidated Delegate Proposal
I don't think anything is missing from your previous posts, nor do I think you've missed anything from other's previous posts. I think we've discussed this issue thoroughly from all sides. As you say, It is a different way of thinking about what OpenID is doing. In other words, it's a worldview thing. One worldview is that the IdP should handle all delegation/synonym management. Another worldview is that the RP can handle it in certain use cases and the IdP in others. The first worldview requires only one identifier parameter. The latter worldview works better with two. When it comes down to a conflict in worldviews, there's no point in further technical debate. We just have to vote and move on. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, October 17, 2006 10:59 PM To: Recordon, David Cc: specs@openid.net Subject: Re: Consolidated Delegate Proposal I don't see there being general consensus. I think Chris Drake was supportive of there being less disclosure as well. Josh said it could be any of the three, but preferred two parameters. Brad did not really care. I do care and would like to see direct criticism on the explanation I wrote about how the protocol works. It is a different way of thinking about what OpenID is doing, and I think it is a useful view that makes it simpler. The RP does not need to worry about the delegation mechanism. There is only one identifier moving around. The concept that there is an RP identifier and an IdP identifier is not needed. What is missing from my previous posts? Throw me a bloody bone here so that I know what I am missing. -- Dick On 17-Oct-06, at 3:20 PM, Recordon, David wrote: I'm also echoing what Josh has said. There has been significant discussion on this issue and there seems to be general consensus, excluding Sxip, that the protocol should have two parameters. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Tuesday, October 17, 2006 5:24 PM To: Dick Hardt Cc: specs@openid.net Subject: Re: Consolidated Delegate Proposal On 10/17/06, Dick Hardt [EMAIL PROTECTED] wrote: 2. It is explicit what is going on from an implementation and specification perspective And I see the opposite. What the RP sends the IdP is just a hint. What the IdP sends the RP is authoritative. I see having two parameters as implying more meaning then is really there. The IdP sending two identifiers *in the response* as the important part. The IdP is only authoritative *if discovery says it is*. There is no more meaning to the response than I am asserting that when you do discovery, you will find that this information is true. What other meaning do you see? Did you read what I wrote? Was there something you did not understand? Perhaps you can point out what you disagree about what I wrote? It's possible that I misinterpreted the RP is figuring them out anyway. I took this as questioning why two identifiers is an improvement over the current (delegate only) model. My answer to this question was it is explicit what is going on from an implementation and specification perspective. This statement was motivated by implementation experience and experience writing about this issue in OpenID 2 drafts. I believe that the two identifier approach will be easier. I also believe that if I had spent the time that I've spent arguing about this issue in documentation and implementation, the world would be better off, regardless of which of the three viable options for identifier portability had been chosen. I repeat, ALL THREE OPTIONS ARE VIABLE. There are trade-offs for all of them. You know which trade-offs I'd make. I know which ones you'd make. We just need to make a decision so that we can spend our energy and time on things that will make a difference to end-users. This is my last word on this list about this issue, unless there is significant insight. I am not going to change my votes. If you want to discuss it more off-list, I'm willing, but I think that'd just be wasting both of our time. Josh ___ 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: Identifier portability: the fundamental issue
+1. Trust is not a boolean. Martin, that's very quotable. Can I attribute it to you? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Monday, October 16, 2006 12:25 PM To: specs@openid.net Subject: Re: Identifier portability: the fundamental issue Chris Drake wrote: There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. If I'm using one IdP to assert my primary public identity, they can hypothetically develop quite a profile about me. I probably don't mind too much in most cases, because I researched them and found that they are a good provider and won't sell my data out to the bad guys. However, there might be some things I want to do (for example, posting locally-prohibited speech on a public forum) that I don't want attached in any way, shape or form to my public identity. The trust relationship I have with that IdP probably isn't enough for this; if there is any record at all of any association between these two identities, as friendly as my IdP may be, there is a chance that it will be ceased by court order, or leaked by an insider, which might lead to me getting in serious legal trouble. This is just one (perhaps extreme) example of why my trust in my IdP is not universal and all-encompassing. Trust is not a boolean. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Summarizing Where We're At
My votes on three issues (0 on everything else): Consolidated Delegation Proposal * -1 on status quo (draft 10) * +1 on two-identifier Change default session type * +1 Bare request * +1 =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Monday, October 16, 2006 3:24 PM To: Josh Hoyt; specs@openid.net Subject: RE: Summarizing Where We're At And here are my votes: Request nonce and name * Take no action Authentication age * -1, write as an extension first Remove setup_url * 0 for removing, +1 for asking feedback from implementers Consolidated Delegation Proposal * -1 on status quo (draft 10) * 0 on single-identifier * +1 on two-identifier Change default session type * +1 Bare request * 0 --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Monday, October 16, 2006 11:21 AM To: Recordon, David Cc: specs@openid.net Subject: Re: Summarizing Where We're At Here are my reactions to what's outstanding: On 10/15/06, Recordon, David [EMAIL PROTECTED] wrote: * Request Nonce and Name - Has been partially implemented, openid.nonce - openid.response_nonce, no agreement on the need of a request nonce specifically, rather discussion has evolved into allowing a RP to pass appdata like in Yahoo's BBAuth. No formal proposal on the table yet, thus will not be included in this version. Take no action * Authentication Age - Re-proposed today adding clarity in motivation, general consensus is needed to add to specification. -1 * Remove setup_url - Little discussion and no general consensus to do so. Rather seems asking for feedback from checkid_immediate implementers on the parameter would be beneficial at this time. +1 * Consolidated Delegation Proposal - Very active discussion, the only proposal I'm willing to stall the spec for. Seems very important a strong conceptual model is created at this time. -0 on status quo (draft 10) +0 on single-identifier +1 on two-identifier * Change Default session_type - Proposed, no discussion yet. Will address in separate message * Bare Request - Proposed, no discussion yet. -0 (YAGNI) Josh ___ 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: Re[2]: Identifier portability: the fundamental issue
Chris, I think you may have me mistaken for somebody else on the list (DR is also David Recordon). I'm a big fan of IdP-initiated login and privacy protection in OpenID. However as much as I think that's an important use case, there's also many use cases around using a public, omnidirectional identifier. So OpenID should accommodate both. =Drummond -Original Message- From: Chris Drake [mailto:[EMAIL PROTECTED] Sent: Monday, October 16, 2006 8:29 PM To: Drummond Reed Cc: 'Martin Atkins'; specs@openid.net Subject: Re[2]: Identifier portability: the fundamental issue Hi Drummond, DR ... if there is any record at all of any association between these DR two identities, ... double-blind anonymous authentication solves this problem. The RP knows nothing more about you besides: A) you're authenticated, and/or B) you've been here before (eg: have signed up for an account) The IdP knows merely C) That you wanted to log in somewhere The RP does not know your ID or even your IdP, and your IdP does not know what site you logged in to. I have a working proof-of-concept that I demonstrated to a few people some months back, let me know if you've not seen it, and I'll send over the URL In a nutshell - this relies on uniform nonce formats and asymmetric cryptography (so the RP and IdP can talk between one another without making any actual contact - the browser and/or user carry the authentication payloads forth and back without referrer URLs or any other info that can link the 2 sites (RP/IdP) together). Besides all that - the normal use case for an IdP in OpenID world (remember: decentralized) will be someone running some open-source code on their own server, so trust in this instance *is* boolean: at least in so far as if there's anything for someone to not be trustworthy about themselves for - it won't be the fault of their IdP code PROVIDING their IdP has provided them with IdP-initiated logins in order to allow this user to protect their own privacy in the first place. Court orders are what I termed 3.5. Authorized exploitation in my threat list, and insider leaks I called 1.3.6. physical attack of server resources (eg: server/hosting-facility compromise) - there's another 98 other threats to keep in mind here as well:- http://chrisdrake.com/Comprehensive_list_of_Threats_to_Authentication_Proced ures_and_Data.html While your example might seem extreme, the consequences are also extreme (or fatal, if you live someplace like China) - which is why I take privacy so seriously. Stick Himalayas video into google news if you want to watch what Chinese do to their own people when found trying to visit the Dalai Lama. Now - how comfortable are you with the idea of letting 1.5 billion Chinese people use OpenID without making it easy to help them protect their own privacy ? There's a big picture here, and it's not about meeting some arbitrary deadline or saving a day or two of coding work - it's about producing something that works, and can be deployed ethically. Take a long hard look at that Nun lying dead in the snow, then tell me you still believe there's no need for IdP-initiated privacy protection in OpenID. Kind Regards, Chris Drake, =1id.com Tuesday, October 17, 2006, 7:29:00 AM, you wrote: DR +1. Trust is not a boolean. Martin, that's very quotable. Can I attribute DR it to you? DR =Drummond DR -Original Message- DR From: [EMAIL PROTECTED] DR [mailto:[EMAIL PROTECTED] On Behalf DR Of Martin Atkins DR Sent: Monday, October 16, 2006 12:25 PM DR To: specs@openid.net DR Subject: Re: Identifier portability: the fundamental issue DR Chris Drake wrote: There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. DR If I'm using one IdP to assert my primary public identity, they can DR hypothetically develop quite a profile about me. I probably don't mind DR too much in most cases, because I researched them and found that they DR are a good provider and won't sell my data out to the bad guys. DR However, there might be some things I want to do (for example, posting DR locally-prohibited speech on a public forum) that I don't want attached DR in any way, shape or form to my public identity. The trust relationship DR I have with that IdP probably isn't enough for this; if there is any DR record at all of any association between these two identities, as DR friendly as my IdP may be, there is a chance that it will be ceased by DR court order, or leaked by an insider, which might lead to me getting in DR serious legal trouble. DR This is just one (perhaps extreme) example of why my trust in my IdP is DR not universal and all-encompassing. Trust is not a boolean. DR ___ DR specs mailing list
IdP term in spec (was RE: Delegation discussion summary)
Suggestion: sidestep the issue completely and in the spec -- and everywhere else -- just call it OpenID provider. It's a simple concatenation of OpenID and service provider, so everyone gets it, but nobody will associate it with SAML or federation or anything else. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Saturday, October 14, 2006 11:37 PM To: specs@openid.net Subject: Re: Delegation discussion summary We call it identity host at NetMesh. It's close enough to identity provider so people understand it quickly, but does not have the provider part to it (duh). On Oct 14, 2006, at 20:46, Scott Kveton wrote: I would propose that the term Homesite be used when prompting the user to type in their IdP. I think the term Identity Provider is overloaded and not user friendly. As per my last email I feel the same way about identity provider as well ... I agree with Dick; too overloaded and not user friendly. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
Chris, I totally agree that: a) OpenID Authentication 2.0 should support yours scenario of IdP-initiated login, and b) that this enables a whole range of privacy solutions, many of which can be supported by IdP innovation. If IdP-initiated login were the only use case, then only one identifier would be needed. It's the use cases for RP-initiated login that argue for having a second identifier parameter in the protocol. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Friday, October 13, 2006 9:19 PM To: specs@openid.net Subject: Re: Identifier portability: the fundamental issue Hi Drummond, DR CASE 1: the protocol supports only IdP-specific identifiers and no portable DR identifiers. DR RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Please explain? If I've got an OpenID URL (eg: my vanity domain), I can transfer this via DNS (or just update my OpenID LINK). If I've got an i-name, I can transfer this too. Where's the lock in ? I do not believe the RP needs to know the IdP-specific identifier ever (worse: I think it should never be allowed to know it, or even be allowed to see it!). Yes - we need 2 identifiers - but from the point of view of the specs - the OpenID protocol really only needs to deal with one. There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. Can we not adopt my earlier suggestion: just ensure OpenID can permit IdP-initiated logins. This permits every scenario of portability (and privacy) that everyone wants, without us having to continue to debate it ? This really *is* only an hour or two's worth of code: after which, market forces can decide which bells and whistles relating to portability and privacy the IdPs choose to implement - from the OpenID point of view, it's all just going to work. Kind Regards, Chris Drake, =1id.com Saturday, October 14, 2006, 5:59:23 AM, you wrote: DR CASE 2: the protocol supports only portable identifiers and no IdP-specific DR identifiers. DR RESULT: IdP is forced to know and store all portable identifiers for a user, DR including identifiers for which the IdP is not authoritative, and users DR would be forced to register all their portable identifiers with their IdP, DR and to update these registrations every time the user adds or deletes a DR portable identifier. Highly undesirable if not impossible. DR * DR Please post if you do not agree with this postulate. DR =Drummond DR ___ DR specs mailing list DR specs@openid.net DR 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: Delegation discussion summary
Hans, This has come up a few times and the mapping between the portable identifier and the IdP-specific identifier is available in public XRDS documents. So there's no point in trying to hide that information from the IdP -- and it may even be misleading to suggest to end-users that they could try to do so. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Granqvist, Hans Sent: Friday, October 13, 2006 8:52 AM To: Josh Hoyt; specs@openid.net Subject: RE: Delegation discussion summary I can see potential use-cases where Alice doesn't want the idp to know what her portable URL is. This would not work if the protocol requires both as per below. Can it be solved by sending a hash of the portable identifier? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, October 12, 2006 10:29 AM To: specs@openid.net Subject: Delegation discussion summary Hello, list, I'm sure that another message in your inbox with delegation in the title makes most of you cringe, so I'm sorry for that.I hope that this one gets us closer to resolving this issue. I have attempted to summarize the proposed delegation mechanisms, as well as the currently-specified delegation mechanism in a single document. I have glossed over some issues and left out some of the discussion, but I hope that I captured most of the important stuff. After reviewing the discussion, I think that we are actually pretty close to consensus on a course of action. I have added one new thing in this write-up, which is that I have started calling delegation portable identifier support, which gives rise to the term portable identifier for what is currently called a delegated identifier. I think that this terminology is a little easier to understand and less loaded than calling it delegation. My write-up follows. Josh OpenID portable identifier support ## Portable identifier support allows an IdP to do authentication for an identifier that was not issued by that IdP. It has two motivating use cases [1]_: * allow users to use any identifier with any IdP * allow users to move an identifier between IdPs (prevent IdP lock-in) Each portable identifiers has an IdP-specific identifier tied to it. This identifier allows the IdP to know what credentials to require before issuing an authentication response even though the IdP does not control the portable identifier. Throughout this discussion, I will assume that there is a portable identifier called http://my.portable.url/; that uses an IdP-specific identifier called http://my.idp.specific.url/;. Current implementation == OpenID 1 [2]_ calls portable identifier support delegation. In this implementation, the IdP-specific identifier is the only identifier that is communicated between the relying party and the IdP. When a relying party discovers that it is requesting authentication for a portable identifier, it must keep that state available for processing the response, since the response message does not contain the portable identifier at all. Request and response messages for this mechanism both use the following field:: openid.identity = http://my.idp.specific.url/ This mechanism has a few drawbacks: * The relying party must manage state information for the duration of the transaction. * The authentication messages are potentially confusing, since the authentication response is not meaningful without the context of the initiation, and the IdP-specific identifier does not even have to be a valid OpenID identifier. * The IdP *cannot* be aware that it is using a portable identifier, so the IdP cannot assist the user in making decisions for different identifiers. For example, a user might wish to be prompted for confirmation each time he used one identifier, but allow automatic approval for another. * IdP-driven identifier selection in the OpenID 2.0 specification (up to draft 9) cannot return assertions for portable identifiers, because the verification algorithm will fail. * Portable identifiers must be treated differently from IdP-issued identifiers by the code running on the relying party Proposed changes All of the changes to delegation that have been proposed retain the important features of portable identifier support. Additionally, they all retain the same basic structure, where the IdP-specific identifier is available from the standard discovery process. Primarily, the proposals change what data is available in the protocol messages, the relationship of the request to the response, and/or the party who is responsible for discovering the IdP-specific identifier for the portable identifier. Both of the proposed changes
RE: Delegation discussion summary
But I suggest we move that terminology discussion to the marketing list. What marketing list? http://lists.iwantmyopenid.org/mailman/listinfo/marketing. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Use of i-numbers (was RE: Consolidated Delegate Proposal)
Martin wrote: I think this is the intention, though it does show an interesting inconsistency between the use of XRIs and the use of i-numbers. I currently have three URL-based identifiers all pointing at the same server and the same Yadis document, yet those identifiers are distinct. However, in the comparable XRI case, it would appear that those identifiers would all be considered to be the same. If they point to the exact same XRDS document with the same i-number as the CanonicalID, that would establish all three URLs and the CanonicalID i-number as synonyms (yes, it is possible to have URLs and XRIs that are synonyms). In XRI Resolution 2.0 Working Draft 11 we are adding a new BackRef element that will enable an XRDS document to back reference any type of identifier that points to it, such as a URL, so you can machine-verify the back reference if you want. If you wanted to keep the three URLs as distinct, separate identities, point them at three different XRDS documents with different i-numbers. I wonder how easy it is to get hold of new i-numbers. If they are basically throw-away cheap, then I'm able to decide for myself how to distribute my mappings to separate them. However, if these i-numbers are going to be expensive (for some sense of the word) to aquire, I've got less freedom in this respect. Drummond? The short answer is that delegated i-numbers (and this is the federated identifier meaning of the term delegation) are as throw-away cheap as URL (at the path level), third-level DNS names, or any other form of delegated identifier. The cost is all in resolution, i.e., someone somewhere maintaining a registry that will point you to the XRDS document if you resolve it. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
Marius wrote: I was suggesting that portability can be resolved between the user and the IdP. I cannot see how the protocol can help this by passing two identifiers. And if only the portable identifier is passed then there is no need to mention the IdP-specific identifier. Marius, see the analysis at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now updated to include Josh's lastest thinking from http://openid.net/pipermail/specs/2006-October/000357.html. In sum, not being able to send the IdP-specific identifier: a) forces the IdP to redo resolution, which is unnecessary and slows performance, and Not necessarily. When you register with the IdP most likely you will claim all your portable identifiers with this IdP, so the IdP knows about them. With XRI i-name/i-number infrastructure that's neither practical nor desirable. With XRIs, users control their own synonyms, i.e., I can register a delegated i-name within a specific community (for example, at @example.community I could register @example.community*drummond) and then point that at my personal i-name (=drummond.reed) and the IdP for =drummond.reed will never know -- and doesn't need to know. I could go to any RP and login in as @example.community*drummond, the RP will resolve this to =drummond.reed (through the way XRI resolution automatically handles reference processing -- let me know if you want more info about this), and end out storing the CanonicalID i-number for =drummond.reed (which is =!F83.62B1.44F.2813). b) prevents the protocol from being stateless. How? The RP deals only with the portable identifier and this is the only thing the IdP sends back. Why do you need state? It follows from the above. But this is so important that I'm going to send a separate message about it. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Identifier portability: the fundamental issue
Yesterday we established consensus that with OpenID, identifier portability is sacred. Today I'd like to establish consensus on the following postulate: To achieve identifier portability in OpenID, it MUST be possible for the RP and the IdP to identify the user using two different identifiers: an identifier by which the RP knows the user (the portable identifier), and an identifier by which the IdP knows the user (the IdP-specific identifier). I would submit that if this postulate is true, then OpenID Authentication 2.0 requires two identifier parameters because if the protocol only allows sending one, then: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and 2) If the RP sends the portable identifier, an IdP is forced to do a resolution a second time after the RP has already done resolution (bad). OTOH, if the postulate is false, then a case can be made for OpenID Authentication 2.0 having just one identifier parameter. PROOF CASE 1: the protocol supports only IdP-specific identifiers and no portable identifiers. RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. CASE 2: the protocol supports only portable identifiers and no IdP-specific identifiers. RESULT: IdP is forced to know and store all portable identifiers for a user, including identifiers for which the IdP is not authoritative, and users would be forced to register all their portable identifiers with their IdP, and to update these registrations every time the user adds or deletes a portable identifier. Highly undesirable if not impossible. * Please post if you do not agree with this postulate. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
Drummond wrote: To achieve identifier portability in OpenID, it MUST be possible for the RP and the IdP to identify the user using two different identifiers: an identifier by which the RP knows the user (the portable identifier), and an identifier by which the IdP knows the user (the IdP-specific identifier). Hans wrote: There is no reason why the idp MUST require to know both identifiers for identifier portability to be possible in the system. Brad wrote: Existence proof: OpenID 1.1 does identifier portability without two identifiers in the spec. Just to clarify: the postulate above did not mean to imply there must be two different identifiers in the spec/protocol. It was just meant to assert that the principle of identifier portability (upon which we already have consensus) requires that it be possible for the RP and IdP to use two different identifiers. I was hoping to inch our way towards consensus here by seeing if we had agreement on this second principle (as some messages have been implying that IdP-specific identifiers were not needed at all). And despite all the but it can't be stateless without two! noise, it actually can: you put the portable identifier in the return_to URL and verify it again when you get the signature back from the IdP. That is, verify the mapping from portable - IdP-specific still holds. Because you can't just trust the 1 (or 2) values you get back from the IdP, otherwise the IdP (which could be malicious) could be fucking with you, asserting a portable identifier which it's not actually permitted to do, according to the portable identifer's YADIS/head/etc. Good point. I've never figured an attack vector for the RP to send the wrong identifiers to the IdP, since the RP is just fooling itself. But I agree there can be one for a malicious IdP to return the wrong ones to an RP. So with 1 or 2, you still need to verify, but that verification doesn't have to be painful: you can cache it. But that's state! omg! Okay, so don't cache it and re-check it. But OpenID's been all about the state(caching) vs. roundtrip(slow) for some time, so it's a fair tradeoff. Agreed. Counter-argument: but OpenID 1.1 does have two parameters: one's just in the return_to URL and managed by the client library, arguably in its own ugly namespace (not IdP/RP managed, not openid., but something else... the Perl library uses oic. or something). So then it's harder to document the correct behavior to people (RPs should verify the mapping when you get a signature!) because the parameter names aren't consistent between RP clients. Agreed, and you articulated well the reasons for doing it at the spec level. So whether it's in the spec formally or not, I don't really care. But the spec MUST contain details on the precautions a RP should take. Yup.(Got that, editors?) =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
+1. Josh, you did a great job of not just distilling it down to the essence, but also nailing the right semantics for the underlying feature, which is identifier portability. Nice work. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, October 12, 2006 10:29 AM To: specs@openid.net Subject: Delegation discussion summary Hello, list, I'm sure that another message in your inbox with delegation in the title makes most of you cringe, so I'm sorry for that.I hope that this one gets us closer to resolving this issue. I have attempted to summarize the proposed delegation mechanisms, as well as the currently-specified delegation mechanism in a single document. I have glossed over some issues and left out some of the discussion, but I hope that I captured most of the important stuff. After reviewing the discussion, I think that we are actually pretty close to consensus on a course of action. I have added one new thing in this write-up, which is that I have started calling delegation portable identifier support, which gives rise to the term portable identifier for what is currently called a delegated identifier. I think that this terminology is a little easier to understand and less loaded than calling it delegation. My write-up follows. Josh OpenID portable identifier support ## Portable identifier support allows an IdP to do authentication for an identifier that was not issued by that IdP. It has two motivating use cases [1]_: * allow users to use any identifier with any IdP * allow users to move an identifier between IdPs (prevent IdP lock-in) Each portable identifiers has an IdP-specific identifier tied to it. This identifier allows the IdP to know what credentials to require before issuing an authentication response even though the IdP does not control the portable identifier. Throughout this discussion, I will assume that there is a portable identifier called http://my.portable.url/; that uses an IdP-specific identifier called http://my.idp.specific.url/;. Current implementation == OpenID 1 [2]_ calls portable identifier support delegation. In this implementation, the IdP-specific identifier is the only identifier that is communicated between the relying party and the IdP. When a relying party discovers that it is requesting authentication for a portable identifier, it must keep that state available for processing the response, since the response message does not contain the portable identifier at all. Request and response messages for this mechanism both use the following field:: openid.identity = http://my.idp.specific.url/ This mechanism has a few drawbacks: * The relying party must manage state information for the duration of the transaction. * The authentication messages are potentially confusing, since the authentication response is not meaningful without the context of the initiation, and the IdP-specific identifier does not even have to be a valid OpenID identifier. * The IdP *cannot* be aware that it is using a portable identifier, so the IdP cannot assist the user in making decisions for different identifiers. For example, a user might wish to be prompted for confirmation each time he used one identifier, but allow automatic approval for another. * IdP-driven identifier selection in the OpenID 2.0 specification (up to draft 9) cannot return assertions for portable identifiers, because the verification algorithm will fail. * Portable identifiers must be treated differently from IdP-issued identifiers by the code running on the relying party Proposed changes All of the changes to delegation that have been proposed retain the important features of portable identifier support. Additionally, they all retain the same basic structure, where the IdP-specific identifier is available from the standard discovery process. Primarily, the proposals change what data is available in the protocol messages, the relationship of the request to the response, and/or the party who is responsible for discovering the IdP-specific identifier for the portable identifier. Both of the proposed changes to the response messages include the portable identifier in the authentication response. Changing the response to contain the portable identifier removes the burden of maintaining that state from the relying party. Removing this dependency on transaction state enables portable identifiers to be used in both IdP-driven identifier selection and IdP-initiated authentication (bare response) [3]_. Neither proposal outlined here changes the protocol unless a portable identifier is used. Both portable and IdP-specific identifiers -- Include both the portable identifier and the IdP-specific identifier in the request and response ([4]_ and [5]_):: openid.identity =
RE: Delegation discussion summary
+1 to Josh's point. IMHO identifier portability is sacred. If anyone disagrees, please post, can we assume we have consensus on this? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, October 12, 2006 8:56 PM To: Marius Scurtescu Cc: specs@openid.net Subject: Re: Delegation discussion summary On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote: The protocol does not need to touch on IdP-specific identifiers (aka delegated identifiers) at all IMO. If there is a specified mechanism that must be supported for using a portable identifier, all IdPs will support it, so identifiers will actually be portable. You'd have a very difficult time trying to get people here to remove portable identifier support from the OpenID protocol. Josh ___ 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: Delegation discussion summary
Title: RE: Delegation discussion summary +1 to getting it done. This area of terminology is more a usability/marketing issue at this point. I agree we need to converge on good, simple user-facing terms for describing OpenID in ways ordinary Web users can easily understand. Although I have great respect for Dick Sxips pioneering work in this area, I dont believe terms that use the word site are the right metaphor, and the concept of membersite, while good for the context Sxip originally used it, would send the wrong message about OpenID. But I suggest we move that terminology discussion to the marketing list. =Drummond From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, October 12, 2006 9:04 PM To: Gabe Wachob; Graves, Michael; specs@openid.net Subject: RE: Delegation discussion summary I'd have to agree with Gabe about this, let's get it done! :) -Original Message- From: Gabe Wachob [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 12, 2006 05:43 PM Pacific Standard Time To: Graves, Michael; specs@openid.net Subject: RE: Delegation discussion summary *If* we are going to open up the terminology discussion, for me the terms authenticating party (formerly the IDP) and accepting party (formerly the relying party) seem more descriptive. The authenticating party issues authentication assertions in the form of special HTTP request/responses with the other party, who then accepts these assertions and decides whether or not they are good enough to let a user do something. As far as Dick's terminology, I'm not sure how membersite makes sense here. Perhaps it's a matter of history or perspective that I haven't been enlightened on. In any case, I'd rather get openid 2.0 out sooner than have a long discussion on terminology, so I won't push this any further unless someone else really thinks its valuable. Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Graves, Michael Sent: Thursday, October 12, 2006 5:00 PM To: specs@openid.net Subject: RE: Delegation discussion summary Josh, et al, I believe the first of your options -- Both portable and IdP-specific identifiers -- is the superior choice here. It preserves OpenID 1 semantics, and unambiguously makes room for portable identifiers. I don't see the added burden carried by relying party code for this option viz. portable identifiers only as being significant. Recommend we proceed with the both strategy. Also, this may be throwing a wrench in the gears here, but I'd like to toss in the idea of using this point in time to pivot on our terminology and look at adopting Dick Hardt's terminology here. Portable identifiers are a powerful upgrade in and of themselves, and get us off the IDP lock-in hook that I've been hung up with customers on now a couple times. But as we move away from explicit IdP-specific URLs as the only identifier, I think that the Sxip homesite model becomes more important to consider as well. I very much like the idea of entiring in my homesite URL at a participating membersite (OpenID relying party), say http://myidmanager.com and during the authentication process, being able to choose from one of n available personae managed for me by myidmanager.com. So my final identifier may be http://myidmanager.com/73648729 or even http://graves.isnuts.com. I won't delve into where we are with respect to that capability here, but want to suggest that maybe as we move to OpenID 2.0, and now offer portable IDs (as well as run-time chosen IDs selected at auth-time?), we may be wise to just make the jump to using homesite and membersite across the board, rather than IdP and relying party, both of which are technically problematic for our framework. Anyway, that's a bit off topic, but something to consider. In any case, the both option below gets my vote. Good work Josh! -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Josh Hoyt Sent: Thursday, October 12, 2006 12:29 PM To: specs@openid.net Subject: Delegation discussion summary Hello, list, I'm sure that another message in your inbox with delegation in the title makes most of you cringe, so I'm sorry for that.I hope that this one gets us closer to resolving this issue. I have attempted to summarize the proposed delegation mechanisms, as well as the currently-specified delegation mechanism in a single document. I have glossed over some issues and left out some of the discussion, but I hope that I captured most of the important stuff. After reviewing the discussion, I think that we are actually pretty close to consensus on a course of action. I have added one new thing in this write-up, which is that I have started calling delegation portable identifier support, which gives rise to the term portable identifier for what is currently called a delegated identifier. I
RE: Consolidated Delegate Proposal
David, Based on feedback, I've backed openid.display out of the consolidated proposal at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. This simplifies it to just two parameters, openid.identity and openid.rpuserid, which I believe now meet both Josh's and Martin's use cases. =Drummond -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 9:38 AM To: Drummond Reed; specs@openid.net Subject: RE: Consolidated Delegate Proposal In terms of openid.display, shouldn't the IdP greet the user in whatever manner it uses? Thus if the user has an account on the IdP, the IdP should always greet the user in the same manner with it. Seems like both a usability, phishing, and potential XSS issue if the IdP greets the user with a string from the RP. Am I just missing something there? --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 1:20 AM To: Recordon, David; specs@openid.net Subject: RE: Consolidated Delegate Proposal David Recordon wrote: Read through it (http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), and I'm liking how it really clears up delegation. A few questions: 1) In case 1, is what the user typed in ever sent from the RP to the IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered their identifier on the RP? Or in the case where the IdP supports multiple identifiers for the user, shouldn't the RP send what the user entered so the user doesn't have to choose it again at their IdP? Case 1 is the directed identity case. The RP *could* send what the user types in at the RP (the identifier for the IdP's directed identity server), but since the RP knows (from the OpenID service type) that this is an anonymous login, and thus that the RP needs to get openid.rd_user_id *back* from the IdP, it seemed better for the RP not to send anything. This way you never break the rule that the IdP never changes any of the identifier parameters than an RP sends it. 2) This may also be part of my first question, but why is there such a delta between case 1 and cases 2 and 3? How does the RP know to use case 1 versus case 2, they seem quite similar in their explanation? Again, Case 1 is the directed identity case, that's why it's so unusual. The way the RP differentiates between case 1 and cases 2/3/4/5 is that only in case 1 is the value Type attribute in the OpenID service endpoint http://openid.net/identifier_select/2.0;. I went back and rewrote the page to make this much clearer. 3) What is openid.display used for? The complete explanation was in the latter part of http://openid.net/pipermail/specs/2006-October/000278.html. But to make the consolidated proposal easier to review, I added a Summary of Motivations section at the start and put a section at the end explaining the motivation for openid.display. 4) In the rules, don't you mean the IdP must return the value of the rp_user_id for the RP to key off of, not the value of identity? Yes, sorry, this was unclear. What I meant was that since the RP must ALWAYS send openid.identity, the RP could *ALWAYS* count on this in the response. However you're right that as far as a persistent key goes I think this is getting there, just either needs to be tightened up or the different flows better explained. I think it just needed to be better explained. Also, Josh, note that when I went back to edit this tonight, I found the parameter name openid.rp_user_id was driving the wiki markup nuts. So I changed it to just openid.rpuserid. Personally, I think this reads fine and eliminates the awkward underscores. I hope you agree. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: PROPOSAL: OpenID Authentication Flow and how delegate fits in
Dick, While I think I followed most of what you say here, I'm not sure what the exact proposal is. Are you proposing to remove the openid:delegate element in 2.0? And replace it with an indirect identifier request protocol (your step 3 below)? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Monday, October 09, 2006 10:15 PM To: specs@openid.net Subject: PROPOSAL: OpenID Authentication Flow and how delegate fits in I'll start off with a couple new definitions so that we are not hung up on what terms mean: supplied_identifier := what the user types into the RP's form verified_identifier := the identifier that the IdP says the user is When looking at the OpenID protocol, the openid.identity sent from the RP to the IdP can be thought of as just a hint as to what verified_identifier the user wants to be at the RP. Given that, I would describe the flow as such: 1) User provides a supplied_identifier to the RP. The user may type this into a form which will post the supplied_identifier to the RP's login_url or a software agent may post this to the login_url. The supplied_identifier may be an: OpenID URL iname IdP URL 2) The RP then does the appropriate discovery on supplied_identifier to find the IdP's entry point and functionality supported. The delegate tag is ignored if present. 3) If the RP wants to get a verified_identifier for the user, the RP sends an indirect message to the IdP containing openid.identity=supplied_identifier, otherwise openid.identity=none to indicate it does not want a verified_identifier. 4) if a verified_identifier was requested, the IdP determines which verified_identifier the user would like to be with the RP, and then sends an indirect message with openid.identity=verified_identifier to the RP. Although the user may have typed in one OpenID URL or iname, a different one could be in the response back to the RP. 5) If the RP has not already determined that the IdP is authorative for verified_identifier, then the RP does discovery on the verified_identifier to confirm the IdP is authoritative. + The IdP knows what the user typed into the form at the RP since that is what is sent to the IdP. + The IdP can display a friendly name to the user as to what they are releasing. + The IdP can assist the user in determining which verified_identifier they want to be at a site. Eg. the user may have forgotten which verified_identifier they were in the past, and the IdP can ask the user to confirm they want to use a different verified_identifer then the one they have previously used. + works with OpenID 1.1 as even though a 1.1 RP will send the delegate, a 2.0 IdP will send back the verified_identifier. NOTE: The delegate tag is just a token that the user sticks into their HTML so that the IdP knows the user controls that URL. If the IdP controls the URL, then the delegate tag is not needed. ___ 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: XRI canonical id question
Johannes Ernst wrote: Drummond: The current auth draft says in section 11.4: If the Verified Identifier is an XRI, the discovered CanonicalID field from the XRD SHOULD be used as a key for local storage of information about the End User. Is there ever a scenario where the identifier is disassociated from the CanonicalID? I was wondering whether there is a potential security hole? [I simply don't know, so I'm asking you ;-) ] Martin Atkins wrote: I'm pretty sure that i-numbers are never re-assigned. That's a pretty fundamental design principle for XRI, as I understand it. Exactly. It's important to note that while XRI syntax and resolution enable this on a technical level, it's still ultimately a policy that has to be enforced at a registry level. This has always been true of URNs -- as the IETF noted at the conclusion of its URN effort, persistence is an operational characteristic of an identifier, not purely a technical characteristic. (For more on persistent identifiers, I recommend http://www.nla.gov.au/padi/topics/36.html). RPs should ideally be displaying the entered i-name but using the i-number as the primary key. Of course, this does have the possibility that in future the display name may be wrong, but since the RP should be storing both it will be able to detect during auth that the two have become detached and create a new conceptual user, probably disassociating the i-name from the old one in the process. Right on the money. I would go further and recommend that an RP not even store the i-name, just the i-number and a user's preferred display name. That way the i-name becomes really just a convenient way for the user to give the RP their i-number (CanonicalID). This does pose a problem to humans in that the RP will be displaying an incorrect i-name until the new owner tries to authenticate with the same RP, which may never happen. Again, this is why I recommend RPs don't even store the i-name, but instead store their own display name for the user. The display name and the i-number (CanonicalID) never need to change, whereas an i-name may be reassigned. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
Martin wrote: I'm surprised that our resident privacy advocates aren't making a bigger deal out of this. (If the privacy advocates have no problem then I'll let this go, since this isn't a use case I feel particularly strongly about myself.) Dick wrote: I was supportive of keeping the delegate from the IdP until I realized that the delegation was public knowledge and could not be hidden from the IdP. The same argument convinced me, too. If public XRDS documents are what we're using to provide user control of identifier synonyms and thus provide identifier portability -- which is the clearest and cleanest approach we've seen -- then the best thing we can do from a privacy perspective is not mislead users that they are protecting their privacy by using a public OpenID identifier and a private identifier with their IdP. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: XRI canonical id question
On 10-Oct-06, at 11:00 AM, Drummond Reed wrote: Again, this is why I recommend RPs don't even store the i-name, but instead store their own display name for the user. The display name and the i-number (CanonicalID) never need to change, whereas an i-name may be reassigned. Dick wrote: why would an i-name be reassigned? Just like a domain name, an i-name registration can lapse and be returned back into the name pool, where it can be registered by a different registrant. why would an i-number not be reassigned? I-numbers are functionally URNs. They are assigned once by a registry (globally or at any level of delegation) and never reassigned. Even if the registration lapses, it can only be renewed by the original registrant (or their trustee). I-numbers are one of the most unique features of XRI registries. See the XDI.org Global Services Specifications at http://gss.xdi.org for much more than you ever wanted to know about the policies around persistent identifier management. Good lawyers took as many years as the technologists to come up with this stuff ;-) who owns the i-number? The original registrant - forever. Even if they die, they can appoint one or more trustees to continue to own/manage the registration. I thought that who is authorative for an i-name was managed by a registry that was separate from the i-broker, and that mechanism provided the separation of identifier management from IdP. It does. The same way domain name registrations are portable from one DNS registrar to another, global i-name and i-number registration are portable across IdPs (in XDI.org XRI infrastructure they are called i-brokers). The role of the IdP/i-broker, like the role of a DNS registrar, is to perform transactions with the registry on the registrant's behalf, i.e., register, update, delete, and transfer registrations. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
Drummond wrote: Better still, if you could add it to the end of http://www.lifewiki.net/openid/ConsolidatedDelegationProposal and explain how the same motivations and use cases currently covered there (using two identifier parameters) can be satisfied just using openid.identity, that would help use consider everything in one place. Dick wrote: As I ponder this, I don't think that Proposal is a good starting point, but I will elaborate more then I did last time and take a different approach on explaining it. I understand if you don't want to use that proposal as a starting point. I'm just advocating that if you have a new proposal, putting it on the wiki and explaining it in a similar fashion so we can compare the two proposals side-by-side. I'm a big fan of wikis over email when it comes to closing issues (see http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11 for an example of what we've been through to close (almost) all the issues for XRI Resolution 2.0 Working Draft 11 over the last two months). Unfortunately it will not go out until later tonight or sometime tomorrow as I have a string of meetings coming up now. Understood. I myself have meetings all day Wed/Thur, so I won't be able to spend as much time on this in that timeframe either. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
On 10/10/06, Dick Hardt wrote: [openid.rpuserid is the identifier] that the user gave the RP? Josh Hoyt wrote: For URL identifiers, it is the supplied identifer, normalized, after following redirects. In essence, it's the user's chosen identifier. For XRI identifers, it's the canonical ID (i-number). Dick Hardt wrote: This comment led me to want to make sure I understand the requirements of XRI. Q: why would the RP not want the i-name to come back rather then the i-number? The i-number can be derived from the i-name. The i-name is what is user visible. The IdP will make sure the i-name the user is presenting resolves to the i-number the user has presented in the past. Am I missing something? Since the RP has to do discovery on the i-name, the RP already has the i-number (CanonicalID). Further, as explained in previous threads, the CanonicalID is the primary key the RP wants to store for the user, not the i-name, because the i-number is forever while the i-name could change. The RP is also motivated to send the i-number to the IdP for the same reason that the RP is motivated to send the delegate URL (if available): to increase performance by saving the IdP from having to re-resolve the i-name (in the XRI case) or original URL (in the URL case). Lastly, in the case where the identifier-the-RP-stores and the identifier-the-IdP-stores are different, if the RP has already discovered the latter, then the RP can be stateless by sending both to the IdP, knowing it will receive both back in the response. If the RP can only send one identifier to the IdP, it's stuck with a dilemma: * If the RP sends the identifier-the-RP-stores, then it forces the IdP to redo discovery, slowing performance. * If the RP sends the identifier-the-IdP-stores, then the RP cannot be stateless because it has to maintain a mapping between the identifier-the-RP-stores and the identifier-the-IdP-stores. In summary it boils down to this: * If the identifier-the-RP-stores and the identifier-the-IdP-stores are both the same, everything works fine with one identifier parameter, openid.identity. * However if the identifier-the-RP-stores and the identifier-the-IdP-stores are different, several efficiencies and optimizations are possible by enabling protocol messages to send and receive both the identifier-the-RP-stores (openid.rpuserid) and the identifier-the-IdP-stores (openid.identity) That's the proposal currently summarized at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Consolidated Delegate Proposal
Maybe I misunderstood the directed identity protocol. Section 4.2.3.1 of Draft 9 says: *** EXCERPT *** 4.2.3.1. IdP Identifiers If the entered Identifier is an IdP Identifier, the OpenID information is contained in a service element with the following information: * An xrd:Type tag whose text content is http://openid.net/server/2.0; * An xrd:URI tag whose text content is The IdP Endpoint URL *** END *** So in the discovery phase what the RP should find is an xrd:Type tag of http://openid.net/server/2.0;. That's what I meant. Am I missing something? =Drummond -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 9:34 AM To: Drummond Reed; specs@openid.net Subject: RE: Consolidated Delegate Proposal Ok, that makes it more clear. I think this line was part of what was throwing me, If Claimed Identifier is EITHER a URL or XRI that maps to a directed identity server (http://openid.net/server/2.0), the values are: since in the discovery phase it should be finding the type of identifier_select. --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 1:20 AM To: Recordon, David; specs@openid.net Subject: RE: Consolidated Delegate Proposal David Recordon wrote: Read through it (http://www.lifewiki.net/openid/ConsolidatedDelegationProposal), and I'm liking how it really clears up delegation. A few questions: 1) In case 1, is what the user typed in ever sent from the RP to the IdP? What if it is an OpenID Auth 2.0 IdP, but the user entered their identifier on the RP? Or in the case where the IdP supports multiple identifiers for the user, shouldn't the RP send what the user entered so the user doesn't have to choose it again at their IdP? Case 1 is the directed identity case. The RP *could* send what the user types in at the RP (the identifier for the IdP's directed identity server), but since the RP knows (from the OpenID service type) that this is an anonymous login, and thus that the RP needs to get openid.rd_user_id *back* from the IdP, it seemed better for the RP not to send anything. This way you never break the rule that the IdP never changes any of the identifier parameters than an RP sends it. 2) This may also be part of my first question, but why is there such a delta between case 1 and cases 2 and 3? How does the RP know to use case 1 versus case 2, they seem quite similar in their explanation? Again, Case 1 is the directed identity case, that's why it's so unusual. The way the RP differentiates between case 1 and cases 2/3/4/5 is that only in case 1 is the value Type attribute in the OpenID service endpoint http://openid.net/identifier_select/2.0;. I went back and rewrote the page to make this much clearer. 3) What is openid.display used for? The complete explanation was in the latter part of http://openid.net/pipermail/specs/2006-October/000278.html. But to make the consolidated proposal easier to review, I added a Summary of Motivations section at the start and put a section at the end explaining the motivation for openid.display. 4) In the rules, don't you mean the IdP must return the value of the rp_user_id for the RP to key off of, not the value of identity? Yes, sorry, this was unclear. What I meant was that since the RP must ALWAYS send openid.identity, the RP could *ALWAYS* count on this in the response. However you're right that as far as a persistent key goes I think this is getting there, just either needs to be tightened up or the different flows better explained. I think it just needed to be better explained. Also, Josh, note that when I went back to edit this tonight, I found the parameter name openid.rp_user_id was driving the wiki markup nuts. So I changed it to just openid.rpuserid. Personally, I think this reads fine and eliminates the awkward underscores. I hope you agree. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation Proposal Amendment
Dick, The persistent identifier I referred to in this thread was whatever identifier the RP was going to persist (proposed to be called openid.rpuserid on http://www.lifewiki.net/openid/ConsolidatedDelegationProposal). This boils down to: * If Claimed Identifier = URL, then openid.rpuserid = URL * If Claimed Identifier = XRI i-name (reassignable), then openid.rpuserid = XRI i-number (CanonicalID - persistent). Both are discoverable from the XRDS document once the RP has done discovery. That's cases 2/3/4/5 on http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. Thus the only case where the RP does not have an identifier to persist is the directed identity case (Case 1). In that case, the RP does not send openid.rpuserid, but instead receives it back in the response from IdP. =Drummond -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 2:21 PM To: Drummond Reed Cc: 'Josh Hoyt'; specs@openid.net Subject: Re: Delegation Proposal Amendment Drummond How does the RP get a persistent identifier before it has called the IdP? The user could type anything into the form. -- Dick On 6-Oct-06, at 2:22 PM, Drummond Reed wrote: Josh, This is very cool. Adding openid.rp_user_id would give us an unambigous way to represent what I called the RPI in my earlier message: IPI = IdP-Persistent-Identifier = openid.identity RPI = RP-Persistent-Identifier = openid.rp_user_id It doesn't address the third identifier, which I called UPI (User-Presented-Identifier -- the one the user typed in at the RP), but let's leave that aside for now. So as I understand it, the rules would be: * ON THE RP SIDE * The RP ALWAYS does discovery on UPI. Then it applies these tests: 1) If UPI maps to a directed identity server (Typehttp://openid.net/server/2.0/Type), then: openid.rp_user_id = [empty] openid.identity = http://openid.net/identifier_select/2.0; 2) If UPI is an XRI that maps to a CanonicalID AND there is no openid:delegate element in the XRD, then: openid.rp_user_id = CanonicalID openid.identity = CanonicalID 3) If UPI is an XRI that maps to a CanonicalID AND to an IPI (via the openid:delegate element in the XRD), then: openid.rp_user_id = CanonicalID openid.identity = IPI 4) If UPI is a URL that maps to an IPI (via the openid:delegate element in the XRD), then: openid.rp_user_id = UPI openid.identity = IPI 5) Else: openid.rp_user_id = UPI openid.identity = UPI * ON THE IDP SIDE * 6) IdP ALWAYS keys on the value of openid.identity. 7) IdP ALWAYS returns the same value of openid.identity that the RP sent (so the RP can always key off this value in the response). 8) IdP ALWAYS returns the value of openid.rp_user_id UNLESS it was empty, in which case see rule 9a below. 9) IdP MAY or MAY NOT do discovery. The rules are: a) If openid.identity = http://openid.net/identifier_select/2.0;, then IdP prompts User for UPI (or detects cookie, etc.). If UPI != IPI, then IdP does discovery on UPI to get mapping to IPI. IdP authenticates against IPI, but at that point allows user to select the RPI (or generates for the user). IdP returns: openid.rp_user_id = user-selected or IdP-generated RPI openid.identity = http://openid.net/identifier_select/2.0; b) If openid.identity = UPI that IdP does not recognize, then IdP does discovery on UPI to get mapping to IPI. After authentication against IPI, IdP returns: openid.rp_user_id = UPI openid.identity = UPI c) If openid.identity = IPI, IdP does not need to do discovery, but authenticates against IPI and returns: openid.rp_user_id = [value sent by RP] openid.identity = IPI * This all works wonderfully and covers all the use cases -- congratulations! Now, let me make a case for also making the third identifier -- the UPI -- explicit in the protocol. This addresses a specific usability issue that arises due to the fact that XRIs support i-name/CanonicalID separation, which URLs don't. However I believe it can also improve usability for URLs. The motivation is that in cases 2 and 3 above, the openid.rp_user_id that the RP passes to the IdP is going to be an CanonicalID, which is an i-number. This is a very ugly string like: =!F83.62B1.44F.2813 (that's my actual i-number) However the IdP only has the choice of openid.rp_user_id or openid.identity from which to greet me to ask for my authentication credentials. Since these will both be a CanonicalID, this leads to a greeting like: Hello =!F83.62B1.44F.2813. Please confirm that you want to login to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel] All it takes to solve this problem is for the RP to pass the UPI in the authentication request. Then the IdP can say: Hello
RE: Consolidated Delegate Proposal
Dick,
As Josh explains in
http://openid.net/pipermail/specs/2006-October/000296.html, the primary
motivation for openid.display is when the user enters an i-name into the RP.
As Josh puts it:
Basically, =foo and =bar could both be tied to the same i-number. Doing
resolution on =foo and =bar will yield the same canonical id, which means
that they represent one logical entity. Drummond wants the display name to
tell the IdP *which* synonym the user entered at the RP so that the IdP can
present that same synonym in the UI, since the canonical id is both
the IdP user identifier and the RP user identifier, but is not
user-friendly (=!1234.1234.1234.1234)
It boils down to this:
* If what the user enters at the RP is a URL, then there is at least one and
at most two identifiers involved -- the Claimed Identifier and an optional
Delegate Identifier.
* If what the user enters at the RP is an XRI, then there are at least two
and at most three identifiers involved -- the Display Name (i-name), the
Claimed Identifier (i-number -- CanonicalID), and an optional Delegate
Identifier (which is usually the same CanonicalID but does not have to be).
Thus openid.display gives IdPs who support XRIs the ability to echo back to
the user the i-name synonym they typed in at the RP, rather than by their
CanonicalID i-number, which they are about as likely to know as their IP
address.
If we decide that's totally unnecessary -- that it's always okay for an IdP
to just address an XRI user by an internal account name and not the i-name
synonym they used at the RP -- then we can drop openid.display.
=Drummond
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 2:19 PM
To: Drummond Reed
Cc: 'Josh Hoyt'; 'Recordon, David'; specs@openid.net
Subject: Re: Consolidated Delegate Proposal
I have finally got up on this thread and don't see the value of the
openid.display parameter.
The RP does not know who the user is when the user is using OpenID to
login, since that is why the RP is using OpenID, to find out who the
user is.
Having the user type in another parameter just lets the user see the
same thing at the IdP. What's the point?
The user clearly knows they are at two different sites, and I think
it is more important to have a consistent experience at the IdP
across RPs then to have a consistent experience between the RP and
the IdP.
The IdP must know who the user is in order to create a positive
response back to the RP, so the IdP will already have some display
values to show the user.
... so what am I missing?
-- Dick
On 9-Oct-06, at 10:56 AM, Drummond Reed wrote:
Josh, your message arrived while I was writing my reply to David's.
I agree completely that openid.display is primarily useful for i-name
synonyms.
You go on to say, For URIs, the display name *must* be the same as
the RP
user identifier, because there is no other value is verifiable by
the IdP.
I was proposing that openid.display be treated simply a string, so
neither
an RP nor an IdP would ever never resolve it, verify it, use it as
key, etc.
openid.display would default to openid.rpuserid if the RP didn't
send an
openid.display value. And if openid.rpuserid was a CanonicalID,
then an RP
SHOULD at least send the i-name as openid.display.
However if the RP wanted to prompt a user for a short Display Name,
even if
the User's Claimed Identifier was a URL, the RP *could* send this
Display
Name to the IdP, and the IdP *could* display it so the user
experience was
consistent across the two sites.
For example:
At RP site the prompts are:
OpenID Identifier:
Your Preferred Display Name:
The user enters:
OpenID Identifier: example.idp.com/some/long/URL
Your Preferred Display Name: DSR
The RP sends to IdP:
openid.identity = http://example.idp.com/some/long/URL
openid.rpuserid = http://example.idp.com/some/long/URL
openid.display = DSR
The IdP displays:
Hello DSR. Do you want to login to YourFriendlyRP?
Password: []
[Accept Once] {Accept Always] [Cancel]
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Josh Hoyt
Sent: Monday, October 09, 2006 10:28 AM
To: Recordon, David
Cc: Drummond Reed; specs@openid.net
Subject: Re: Consolidated Delegate Proposal
On 10/9/06, Recordon, David [EMAIL PROTECTED] wrote:
In terms of openid.display, shouldn't the IdP greet the user in
whatever
manner it uses? Thus if the user has an account on the IdP, the IdP
should always greet the user in the same manner with it. Seems like
both a usability, phishing, and potential XSS issue if the IdP greets
the user with a string from the RP.
Am I just missing something there?
The display name is only useful for XRI synonyms. Basically, =foo and
=bar could both be tied to the same i-number. Doing resolution on =foo
and =bar will yield the same canonical id, which
RE: [PROPOSAL] Separate Public Identifier from IdP Identifier
+1. Josh is right. Ultimately there are three identifiers involved in all interactions between the User, the RP, and the IdP: 1) User-Presented-Identifier (UPI): the identifier entered by the User at the RP. 2) RP-Persisted-Identifier (RPI): the identifier that will be persisted by the RP in order to recognize the User when next the User returns. 3) IdP-Persisted-Identifier (IPI): the identifier persisted by the IdP against which the IdP will authenticate the user. Here's a simple analysis of how these are used during the different flows: OPENID 1.X 1) User enters UPI 2) RP discovers IPI (if any -- otherwise UPI = IPI) 3) RP sends IPI to IdP 4) IdP authenticates against IPI 5) IdP responds with IPI JOSH'S PROPOSED FLOW 1) User enters UPI 2) RP sends UPI to IdP 3) IdP discovers IPI (if any -- otherwise UPI = IPI) 4) IdP authenticates against IPI 5) IdP responds with UPI OPENID 2.0 DIRECTED IDENTITY FLOW 1) User enters UPI (where UPI = identifier of directed identity server) 2) RP sends special UPI (http://openid.net/identifier_select/2.0;) to IdP 3) IdP discovers IPI 4) IdP authenticates against IPI 5) IdP responds with RPI OPENID 2.0 XRI CANONICAL ID FLOW 1) User enters UPI (XRI i-name) 2) RP discovers RPI (XRI i-number = CanonicalID) 3) RP sends RPI to IdP 4) IdP authenticates against RPI (RPI = IPI) 5) IdP responds with RPI * On this basis, it seems the solution is for the protocol to clearly recognize all three identifier types. This would: a) Support all four flows above. b) Enable RPs and IdPs to all do the right thing at the right time with the right identifier c) Eliminate confusion over which identifier is doing what in each flow. So we would go from openid.identity, which is currently overloaded, to: openid.identity = IPI openid.persist = RPI openid.display = UPI Or whatever names everyone can agree on. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Friday, October 06, 2006 10:34 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier On 10/6/06, Martin Atkins [EMAIL PROTECTED] wrote: * The IdP returns a document naming its authentication endpoint (in the URI field) and a special anonymous token as openid:Token. openid:Token may be the same as the public identifier from the previous step, but this is not required. Anonymous is not a good thing to call this. What IdP-driven identifier selection does is let the IdP help the user choose an identifier. In no way is the response any more anonymous than an identifier that was typed in by the user. It is true that one of the motivations for this feature is the great improvement in the user experience for site-specific identifiers, but the IdP could just as well return a cross-site identifier for the user. Sorry to go on about terminology, but I think it's important for understanding what's really going on. Josh ___ 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: [PROPOSAL] Separate Public Identifier from IdP Identifier
+1 to Kevin's point here -- no second discovery step is needed with an XRI. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Turner Sent: Friday, October 06, 2006 1:58 PM To: specs@openid.net Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier From http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken (change #3): Impact on XRI-based auth: An XRI is, for this purpose, a URI that can be resolved into a URL at which we can do Yadis discovery. Once Yadis discovery begins, flow continues as in the original proposal, where openid:Token can be any URI. It's unclear to me whether you intended this to be a change from the current specification or not, but it is. Yadis discovery on URLs resolved from XRIs is considered redundant, as there's nothing about Yadis discovery that can't be done while resolving the XRI. Since Yadis uses the XRI resolution response format, you even get to use the same code. So was it your intention to add an extra layer to discovery here, or should the above section be reworded? ___ 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: [PROPOSAL] bare response / bare request
On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote: Let me play the dumb customer here and say: * A whole lot of real-world users would love OpenID-enabled bookmarks. * A whole lot of websites would love to offer them. * A whole lot of IdPs would love to provide them. Kevin Turner wrote: Okay Customer, if both websites and IdPs would love it, is it okay if it's something that websites + IdPs can layer on top of the core? If some sites chose not to, and the IdP said login bookmark not available for this site, would that be okay? I guess so. The test I would apply is: If the basic protocol makes it easy to layer on -- in a fashion that will be intereoperable by all RPs and IdPs that support it, then yes, it's okay to let it be layered on. If the basic protocol makes it tricky to implement, and thus not likely to be interoperable between the RPs and IdPs that want to do it, that's not okay. Does that help? =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Consolidated Delegate Proposal
At David's suggestion, to make it easier to follow, I've posted what I believe is a consolidated delegate proposal at: http://www.lifewiki.net/openid/ConsolidatedDelegationProposal This incorporates Josh's original, Martin's, Josh's amendment, and my amendment to Josh's. Josh and Martin, please look this over and either make changes or comment as needed. It will be wonderful to finally close this issue. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Re[4]: [PROPOSAL] authentication age
+1 to one key takeaway from this whole thread: that the marketing/evangelism/messaging around OpenID MUST be very careful to clearly communicate, in Gabe's words, what it can and cannot do right now. Especially when it comes to hard problems like authentication context and circles of trust that SAML and Liberty Alliance have been cranking for 5+ years at. As long as we communicated clearly so expectations aren't raised and then not met then we should give OpenID the runway it needs to grow into those problems, just like 802.11 started thin and grew to become nearly ubiquitous. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabe Wachob Sent: Wednesday, October 04, 2006 9:09 PM To: 'Chris Drake' Cc: specs@openid.net Subject: RE: Re[4]: [PROPOSAL] authentication age Chris- I don't mean to be pessimistic about OpenID *AT ALL* - I truly do believe that OpenID *WILL* get to the point where its valuable for the Visas of the world. I don't want to stall it for the other use cases that are motivating the people who are currently involved - I think OpenID can quickly evolve when needed. OpenID should be as lightweight as needed for the use case - and I so I think OpenID is great where it is. Its just that we have to be clear what its trying to do today and what it is NOT trying to do. I think we'll surprise some people (like you) - but in the long run, the credibility will be there - I *KNOW* the folks who are involved with OpenID are smart and know what it can and cannot do right now. We just have to make sure that its being communicated clearly so expectations aren't raised and then not met... -Gabe -Original Message- From: Chris Drake [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 9:00 PM To: Gabe Wachob Cc: 'Kevin Turner'; specs@openid.net Subject: Re[4]: [PROPOSAL] authentication age Hi Gabe, Beautifully worded, and (IMHO) an extremely valuable real-world opinion. I too believe OpenID is currently a non-starter. I have dual vested interests: I want OpenID to succeed, *especially* for RPs like Visa, since my IdP makes money from supporting OpenID only when OpenID ends up getting used. I also believe that an IdP (and mine in particular) is well suited for deploying secure technology (eg: two factor tokens). If, aside from making OpenID actually *work* for the likes of Visa, we can build in the ability to provide a tangible *benefit* to Visa from using it (that is: allow visa to REQUIRE that a user has authenticate via two-factor means, to an accredited - i.e: explicitly trusted by Visa - IdP) then we've not only cemented the future of OpenID, we've gone an improved a pile of security problems along the way. Kind Regards, Chris Drake 1id.com Thursday, October 5, 2006, 1:41:34 PM, you wrote: GW Chris- GW As someone who has recently come from working in the financial GW sector (Visa), its clear that OpenID is NOT intended for authentication GW where the *relying party* cares about how the authentication is performed. GW At places like Visa and for home banking, this means that OpenID, GW without something more, is clearly a . These relying parties want GW to know exactly how their users are being authenticated because their GW business is all about risk management and creating business opportunities GW around very good knowledge of the risk profile of each transaction type. GW That all being said, I believe it should be possible to layer on GW OpenID a form of IDP control such that a relying party can require a certain GW class or group of IDPs be used when presenting authentication assertions to GW them. The actual *policy* for how these IDPs are approved is probably GW orthogonal to the protocol spec, but secure identification of those IDPs GW (relative to some trust root, etc) could probably be made into an extension GW usable for those parties who want it. GW My guess is that culturally, most people involved in OpenID have GW *not* been interested in addressing these concerns. However, expectations GW need to be better managed around these sort of relying-party cares GW scenarios, because its not obvious without actually reading the specs GW themselves... GW -Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Wednesday, October 04, 2006 8:26 PM To: Kevin Turner Cc: specs@openid.net Subject: Re[2]: [PROPOSAL] authentication age Hi Kevin, Sounds like you're leaning towards a root authority for IdPs who can audit procedures and verify protection in order to sign the IdP's keys? Joe blogger doesn't care much about identity assertions from an IdP, but it's a reasonable bet to expect that a Bank might care... Kind Regards, Chris Drake ___ specs mailing list
RE: openid.delegate explained.
Brad, thanks much for posting this. Having spent a ton of time on identifier abstraction -- largely for the benefit of identifier portability -- I have enormous respect for this feature. So I am committed to being super-careful we don't break it just by renaming it. My proposal was limited to just that: renaming to solve the semantics problem. (Ironically, I even understand how it first got the name delegation. I doubt you or anyone else anticipated the context into which that term would be thrust as OpenID grew, and thus the semantic clash that would arise.) Josh's proposal does affect how the feature actually works, and he's posted separately about that. I agree we should be very careful to make sure any substantive changes don't accidentally break the feature. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Fitzpatrick Sent: Tuesday, October 03, 2006 11:59 AM To: specs@openid.net Subject: openid.delegate explained. I don't care what openid.delegate is renamed to. But I feel strongly it has to survive ... I think it's one of the most important things to OpenID, just not well understood. Let me walk through how it works * User Brad currently uses livejournal.com as his IdP * Brad doesn't want his LJ to be his canonical identifier because a) he has a better one, under his control (bradfitz.com), he's just too lazy or incapable of running an IdP there. b) he doesn't trust that LJ will stay around forever, or it might become evil, stop supporting OpenID, or maybe he might want to switch to a better IdP in the future. * So Brad gives RPs his bradfitz.com identifier. * RPs discover that bradfitz.com's IdP is LiveJournal.com, but LiveJournal.com knows jack shit about bradfitz.com ... and perhaps Brad doesn't trust LJ to know about bradfitz.com ... or fears LJ might charge more to use that feature. etc. In summary, the most important thing is I can change my $4/year identifier's IdP every day without informing anybody or making deals with IdPs, AND IT DOESN'T BREAK MY IDENTITY EVERYWHERE. All those sites that thought I was bradfitz.com still think I'm bradfitz.com ... it's just a different IdP asserting that. Not to mention I can still avoid running my own IdP, adding to the bootstrappability of all this ... because I imagine a lot of people will want vanity-plate identifiers (well, never as cool as =BradFitz !) and getting those early dorks in is important too, but not as important as disconnecting an IdP from an identifier. If a given identifier can only be asserted by one IdP, we have lock-in, and people either don't change IdPs, or change and break their identifiers. So openid.delegate is like cellphone number portability. I urge everybody not to accidentally break this while renaming it. - Brad ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
