Re: [PROPOSAL] Separate Public Identifier from IdP Identifier
... the full proposal on the OpenID wiki: < http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken > I like this. The so-called "normal" case is an optimization. Optimizations done for the convenience of computers should be hidden from users. Cordially, Joaquin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age
I think the 2.0 spec extension mechanism could handle signed credentials. For example, "credentials=" where is of a (string) format that contains a type + signature, say credentials=OATHVIP:WW91IGhhZCB0byBjaGVjaywgZGlkbid0IHlvdT8gOyk= The format could also further specify mechanism types, signer identity, and algorithm(s) used if those are not part of the definition of 'credentials'. Hans > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Drummond Reed > Sent: Thursday, October 05, 2006 2:26 PM > To: 'Chris Drake' > Cc: specs@openid.net > Subject: RE: Re[2]: Strong Authencation (was [PROPOSAL] > authentication age > > Chris, > > Great examples. Signed credentials makes lots of sense. > OpenID AuthN 2.0 doesn't handle them yet but I can completely > understand them in the roadmap. > > =Drummond > > -Original Message- > From: Chris Drake [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 05, 2006 10:51 AM > To: Drummond Reed > Cc: specs@openid.net > Subject: Re[2]: Strong Authencation (was [PROPOSAL] authentication age > > Hi Drummond, > > Example1: RSA would provide a signed response indicating that > the user correctly entered the SecurID token code. > > Example2: The RP would have the public key of the company > that supplies the fingerprint scanning hardware (although > some extra thought as to how a fingerprint ultimately matches > to an Identity is required, which will need an entirely > different information flow to Example1). > > Is Dick a vendor himself? he no doubt knows other ways. > > Kind Regards, > Chris Drake, > =1id.com > > > Friday, October 6, 2006, 3:19:44 AM, you wrote: > > DR> Dick, > > DR> You say, " The strong authentication will be supplied by a vendor > DR> that > has > DR> been certified to provide standardized levels of > authentication. The > DR> IdP will often NOT be the strong auth vendor." > > DR> Can you explain how this might work, i.e., how can the RP have a > DR> relationship directly with the strong auth vendor and not > the IdP? > DR> Would > the > DR> IdP be outsourcing authentication to the strong auth vendor? In > DR> which > case, > DR> isn't the strong auth vendor the IdP? > > DR> =Drummond > > DR> -Original Message- > DR> From: [EMAIL PROTECTED] > DR> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt > DR> Sent: Thursday, October 05, 2006 9:36 AM > DR> To: Gabe Wachob > DR> Cc: specs@openid.net > DR> Subject: Strong Authencation (was [PROPOSAL] authentication age > > DR> The vision I have is that strong authentication to your > IdP will be > DR> common in the future. > > DR> The strong authentication will be supplied by a vendor > that has been > DR> certified to provide standardized levels of > authentication. The IdP > DR> will often NOT be the strong auth vendor. > > DR> The RP will have a trust relationship with the vendor, likely > DR> through a vendor consortium that delegates to vendors that their > DR> product is certified, ie. the RP will not need to trust > each vendor, > DR> just the certification body. > > DR> I would hope that OpenID can be extended over time to be able to > DR> move around these types of strong auth assertions. > > DR> -- Dick > > > DR> On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote: > > >> Chris- > >>As someone who has recently come from working in the financial > >> sector (Visa), its clear that OpenID is NOT intended for > >> authentication where the *relying party* cares about how the > >> authentication is performed. > >> > >>At places like Visa and for home banking, this means > that OpenID, > >> without something more, is clearly a non-starter. These relying > >> parties want to know exactly how their users are being > authenticated > >> because their business is all about risk management and creating > >> business opportunities around very good knowledge of the > risk profile > >> of each transaction type. > >> > >>That all being said, I believe it should be possible to > layer on > >> OpenID a form of IDP control such that a relying party can > require a > >> certain class or group of IDPs be used when presenting > authentication > >> assertions to them. The actual *policy* for how these IDPs are > >> approved is probably orthogonal to the protocol spec, but "secure" > >> identification of those IDPs (relative to some trust root, > etc) could > >> probably be made into an extension usable for those > parties who want > >> it. > >> > >>My guess is that culturally, most people involved in OpenID have > >> *not* been interested in addressing these concerns. However, > >> expectations need to be better managed around these sort of > >> "relying-party cares" > >> scenarios, because its not obvious without actually > reading the specs > >> themselves... > >> > >>-Gabe > >> > >>> -Original Message- > >>> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > >>
Re: [PROPOSAL] Separate Public Identifier from IdP Identifier
Dick Hardt wrote: > > I think "Token" is not a good name, so many other meanings. Perhaps > "handle"? > I agree that "token" is not the best name. "handle" is still not that specific, but at least it isn't used in too many other places. (We do already have an "assoc_handle", however.) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Separate Public Identifier from IdP Identifier
Dick Hardt wrote: > I like making all identifiers work the same way. The wording around > directed identity is somewhat confusing. Would be clearer if there > was a complete description of what happened. ie. complete the > transaction. In Directed Identity, the RP needs to do discovery on > the identifier provided to make sure the IdP is authoritative for it. > Perhaps I've misunderstood how directed identity works, but I figured the flow would work as follows: * The RP initiates Yadis discovery on http://anon.myidp.com/ * 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. * The RP initiates OpenID auth to the named endpoint using the openid:Token. * The IdP notes that the special "anonymous" token has been used, but it knows who the remote user is (via Cookies, for example) so it can generate an identifier and remember that it belongs to that user/RP combo. * IdP responds to RP with the generated public identifier (which *is* publically resolvable, of course.) * RP resolves the IdP-provided public identifier, where the IdP will provide for Yadis discovery and specify that it is authoritative for that URL. * We're done. The important thing is that, just as I've separated the public identifier from the IdP token (or handle, if you like), this separation also applies to the IdP-generated public identifier. (sorry that this is a bit rough. I've not really spent the necessary amount of time preparing the above and I'm in a hurry, so if there are spots where I'm not clear I apologise and I'll clarify later! :) ) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Separate Public Identifier from IdP Identifier
What does Liberty call it? (Gabe ducks..) Some humor for a Friday... -Gabe > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Martin Atkins > Sent: Friday, October 06, 2006 9:42 AM > To: specs@openid.net > Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier > > Dick Hardt wrote: > > > > I think "Token" is not a good name, so many other meanings. Perhaps > > "handle"? > > > > I agree that "token" is not the best name. "handle" is still not that > specific, but at least it isn't used in too many other places. > > (We do already have an "assoc_handle", however.) > > ___ > 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: Strong Authencation (was [PROPOSAL] authentication age
Chris Drake wrote: > Hi All, > > 1. Amazon asks the IdP "Please assert this user is not a Robot" >How can it trust this occurred? > > 2. Amazon asks the IdP "Please re-authenticate this user, via >two-factor, two-way strong authentication" >How can it trust *this* occurred? > > The IdP can *say* it did, but would RPs prefer a "stronger" role to > encourage adoption? (eg: #1 - the RP provides the captcha, and the > hash of the solution, while the IdP returns the solution, or #2 - the > RP provides a nonce and later looks for this nonce in the IdP's > also-signed-by-the-authentication-vendor-technology response) > > i.e.: It might get ugly to try and add this stuff in later if we've > not catered up-front for these kinds of interchanges. > These use-cases seem like a good one, in that it's something that's actually *verifiable*, rather than relying on a trust relationship that probably doesn't exist between RP and IdP. I still don't think this should be in the core spec — core OpenID Auth should be simple — but we should make sure that it's possible to add it via extension and if it isn't adjust the way extensions work to make it possible. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Summarizing Where We Are
Dick Hardt wrote: > On 5-Oct-06, at 4:41 PM, Josh Hoyt wrote: > >> On 10/5/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >>> I think you missed my message arguing why it was important and that >>> being part of the return_to URL made it hard for the functionality to >>> be contained in the library >> I'm not sure I buy this reasoning, since our OpenID 1 libraries add a >> nonce to the return_to URL (which is not hard, since the library needs >> to add stuff to the return_to URL anyway) > > curious as to why the RP library needs to add stuff to the return_to > URL? Does it need to for a OpenID 2.0 call? > One example that springs to mind is that the original Perl OpenID library would, in the delegation case, put the user-supplied identifier in a return_to argument so that it could use that identifier when authentication succeeded. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Request for comments: Sorting fields in signature generation-Call for votes
Behavior needs to be specified before it can be recommended. So the spec MUST specify how to deal with the multiple parameters before it can set the use thereof as NOT RECOMMENDED. Hans > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David > Sent: Wednesday, September 27, 2006 1:13 PM > To: Josh Hoyt; Marius Scurtescu; Brad Fitzpatrick > Cc: specs@openid.net > Subject: RE: Request for comments: Sorting fields in > signature generation-Call for votes > > I don't think multiple parameters with the same name should > be completely disallowed, rather that section 7.1 should > strongly discourage their use. I agree that from the core > authentication standpoint they aren't needed today, though do > understand that in the future there may be a compelling use > case for them. I believe the simplicity that is offered from > not supporting them out weighs the benefit of form handling > with existing forms. > > So +1 to tightening up section 7.1, but -1 to it specifically > allowing multiple parameters with the same name. I believe > the wording should be such that it is "strongly NOT > RECOMMENDED that extensions to OpenID Authentication utilize > GET or POST parameters with the same name". > > Brad, thoughts? > > --David > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt > Sent: Wednesday, September 27, 2006 12:20 PM > To: Marius Scurtescu > Cc: specs@openid.net > Subject: Re: Request for comments: Sorting fields in > signature generation -Call for votes > > On 9/27/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: > > please keep in mind that we are not asking for some fancy new > > technology or feature, just conformance with a very basic an wide > > spread convention of handling parameters in HTTP/HTML. > > As Kevin pointed out, we are not working on the HTTP/HTML > form processing specification. We are working on an > authentication protocol. > Restricting the protocol to forbid multiple parameters with > the same name does not break conformance with anything. > > I think that we have discussed the majority of the technical > issues regarding multiple parameters with the same name. I > could respond to your individual points, but I don't think > that would get us any closer to agreement. > > Can we get +1/-1 on multiple parameters with the same name > from people without @sxip.com or @janrain.com e-mail addresses? > > Clearly, we (JanRain) are -1. > > 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: [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
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[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier
Hi Martin, This is getting very close to what I believe is the main important thing we need in the spec to facilitate privacy, true SingleSignOn, and to help avoid confusing users by getting them to key IdP URLs. The only "tweak" I would like to see is right at the start, and is implemented using OPTIONAL (at the RP) pure client-side stuff (plain HTML or JavaScript). The server-side tweak I'd like to see would be this: An ***IdP*** can *initiate* the OpenID login with the RP using openid:Token. How the User arrived at the RP with this token is not the concern of the RP. (could be javascript, browser plugins, participating IdP helper CGIs, or even the RP itself). The point is - the guts of the authentication process remains unchanged and is backwards compatible, but all the privacy-invasive components that live at the RP are thus made *optional*. Simple as that. User only needs to remember and use one ID. User only needs to type it one time each day (or however long they elect to "stay logged on" for). Datamatching and privacy invasion are eradicated. No need to key custom IdP anonymity URLs ever. Even facilitates double-blind anonymous logins (with inclusion of a simple RP nonce extension). Win-win-win. Kind Regards, Chris Drake =1id.com Saturday, October 7, 2006, 2:49:17 AM, you wrote: MA> Dick Hardt wrote: >> I like making all identifiers work the same way. The wording around >> directed identity is somewhat confusing. Would be clearer if there >> was a complete description of what happened. ie. complete the >> transaction. In Directed Identity, the RP needs to do discovery on >> the identifier provided to make sure the IdP is authoritative for it. >> MA> Perhaps I've misunderstood how directed identity works, but I figured MA> the flow would work as follows: MA> * The RP initiates Yadis discovery on http://anon.myidp.com/ MA> * The IdP returns a document naming its authentication endpoint (in the MA> "URI" field) and a special anonymous token as openid:Token. openid:Token MA> may be the same as the public identifier from the previous step, but MA> this is not required. MA> * The RP initiates OpenID auth to the named endpoint using the openid:Token. MA> * The IdP notes that the special "anonymous" token has been used, but it MA> knows who the remote user is (via Cookies, for example) so it can MA> generate an identifier and remember that it belongs to that user/RP combo. MA> * IdP responds to RP with the generated public identifier (which *is* MA> publically resolvable, of course.) MA> * RP resolves the IdP-provided public identifier, where the IdP will MA> provide for Yadis discovery and specify that it is authoritative for MA> that URL. MA> * We're done. MA> The important thing is that, just as I've separated the public MA> identifier from the IdP token (or handle, if you like), this separation MA> also applies to the IdP-generated public identifier. MA> (sorry that this is a bit rough. I've not really spent the necessary MA> amount of time preparing the above and I'm in a hurry, so if there are MA> spots where I'm not clear I apologise and I'll clarify later! :) ) MA> ___ MA> specs mailing list MA> specs@openid.net MA> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Adoption questions
On Fri, 2006-10-06 at 13:26 +1000, Chris Drake wrote: > Is my understanding accurate: OpenID is unable to support single sign > on. If not - lets assume it's 9am. I just signed on. I can visit > RP#1 then RP#2 then RP#3 and go back and forth all day without > hindrance, until I next sign off - yes? This depends almost entirely on the configuration of the RPs involved, but I think the situation you describe is quite doable. > Privacy: during any hypothetical overheard lunchtime conversation > between The CEO of RP#1 and the CEO of RP#2 - nobody's ever going to > hear this fragment of conversation: "... yeah - that troublemaker is > one of our users too ..." - or are they? Being able to identify troublemakers across sites is one of the chief features of a system like OpenID. It's what enables reputation systems and helps content providers break out of silos. However, if as a user, you don't like that feature, you can use directed identity with OpenID. This requires using an IdP with enough other users to provide you with some degree of anonymity -- if you run your own IdP, and are causing enough trouble to draw attention to yourself, they're likely to figure out that everyone using that IdP is you, no matter how many different identifiers you have it assert. Then you provide different identifiers to RP#1 and RP#2. Under OpenID 1.x this is rather cumbersome to do without custom tools in the user agent, but OpenID 2.0 enables IdP-driven identifier selection, which means your IdP can help you keep track of which identifier you provide to which RP. Also keep in mind that, even in the absence of any global user identifier scheme, the Internet presents other challenges to complete anonymity, e.g. your IP address. The level of technical understanding and aptitude required to avoid detection by those basic means will probably place it out of reach of most casual users. and, as an aside, for a fun read about just what can be done with your IP address in the hands of an outfit like the RIAA's legal team, see http://digitalmusic.weblogsinc.com/2006/08/07/the-riaa-vs-john-doe-a-laypersons-guide-to-filesharing-lawsui/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Separate Public Identifier from IdP Identifier
On Thu, 2006-10-05 at 18:08 -0700, Marius Scurtescu wrote: > The only problem it seems to solve is that of vanity identifiers. > Switching IdPs where you had an IdP issued identity for the original > IdP does not seem to be possible, you have no control over that > original identity so you cannot use it anymore. If you had a vanity > identity with the original IdP then switching only means pointing > your vanity identity to the new IdP. This much is true. > Instead of dealing with vanity identities using the delegate tag why > not let the IdP manage your vanity identities? How does this work? I want to log in to an RP with my vanity identity, what do I enter? How does the RP get from what I enter to my IdP? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Delegation Proposal Amendment
I'd like to amend my proposal for changing the delegation mechanism: Revised Proposal As it stands, "openid.identity" is the identifier by which the IdP knows the user. There is no parameter by which the RP knows the user. I propose to add a field called "openid.rp_user_id" in "checkid_*" and "id_res" that defaults to "openid.identity" if it is missing. This field is the identifier by which the relying party knows the user. This is the identifier on which discovery was performed by the relying party. The name "openid.rp_user_id" is not the best, but it *is* very specific. Other suggestions welcome. Benefits This proposal retains the current behaviour in terms of who is responsible for discovery and verification. It makes the messages between the RP and IdP more explicit. It is completely backwards-compatible. IdP-driven identifier selection can now return a delegated identifier (if the user wishes to do so). Drawbacks = The IdP now has knowledge of the identifier that the user entered at the relying party. Discussion == I think there is general agreement that the protocol messages on the wire can lead to confusing results. I also think that it's easy to get the relying party implementation wrong because it has to keep track of state to ensure that the user gets the right identifier. I don't think that most relying parties will have a problem keeping state, but I think it's not a good idea to make proper behavior (using the right identifier) *depend* on the relying party's implementation of state storage. This proposal is similar in spirit to Martin's proposal, in that it acknowledges that delegation is not really a special case. The main difference is that (a) it is obvious from the protocol messages what is going on and (b) discovery is entirely unchanged. Related threads === Original proposal: http://openid.net/pipermail/specs/2006-September/02.html Brad's explanation of openid.delegate: http://openid.net/pipermail/specs/2006-October/000182.html Regarding the purpose of delegation: http://openid.net/pipermail/specs/2006-October/000170.html Martin's similar proposal: http://openid.net/pipermail/specs/2006-October/000216.html Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier
CHRIS DRAKE'S PROPOSED FLOW 1) User *enters* UPI, but a Discovery Agent intercepts this: UPI does *not* get posted to RP 2) Discovery Agent sends UPI to IdP 3) IdP authenticates against UPI 4) IdP selects appropriate RP-specific IPI 5) IdP initiates authentication with RP using IPI Kind Regards, Chris Drake, =1id.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation Proposal Amendment
> ... > Revised Proposal > > > As it stands, "openid.identity" is the identifier by which > the IdP knows the user. There is no parameter by which the RP > knows the user. > > I propose to add a field called "openid.rp_user_id" in > "checkid_*" and "id_res" that defaults to "openid.identity" > if it is missing. This field is the identifier by which the > relying party knows the user. > ... Josh, Can you propose this in terms of diffs to the current draft so it is glaringly obvious what the proposal means? Also, I think this "diffs to current draft" can be most useful for all proposals as it cuts through the various semantic clouds we all have hanging over our heads ;) Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
IdP-initiated authentication & OpenID-enabled bookmarks
In a conversation with Chris Drake, I realized that I don’t know definitively if IdP-initiated login is supported in OpenID Authentication 2.0. In other words, can a user just login to their IdP/i-broker, lthen follow “OpenID-enabled bookmarks” they have stored there to be directly logged in to sites where the user has logged in before? If so, this “bookmark your OpenID login” feature could become very popular at IdPs/i-brokers. (I suspect this may be part of the “bare message” thread but I confess as to not being fully up-to-speed on that issue.) =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP-initiated authentication & OpenID-enabled bookmarks
On Fri, 2006-10-06 at 12:30 -0700, Drummond Reed wrote: In other words, can a user just login to their IdP/i-broker, lthen follow “OpenID-enabled bookmarks” they have stored there to be directly logged in to sites where the user has logged in before? [...] (I suspect this may be part of the “bare message” thread but I confess as to not being fully up-to-speed on that issue.) Yes, I think that is the most compelling case for the "bare response" proposal. (although there are still unresolved conflicts in my head between that proposal and request nonces.) I don't recall offhand what the tally on that is. But if it doesn't pass, then no, this feature would not be in the OpenID 2.0 core spec, and thus may or may not work in the wild. One can imagine adding that on later, but if it doesn't go in core then it'll have to be something that RPs opt in to, and may not be supported universally. (which might work out okay.) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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
RE: IdP-initiated authentication & OpenID-enabled bookmarks
Kevin, thanks for confirming that this functionality would be supported by the “bare reponse” proposal. In that case, +1 for the bare response proposal being in 2.0, as I think it would be really valuable feature for IdPs to offer (I know XRI i-brokers want it). =Drummond From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Turner Sent: Friday, October 06, 2006 1:20 PM To: specs@openid.net Subject: Re: IdP-initiated authentication & OpenID-enabled bookmarks On Fri, 2006-10-06 at 12:30 -0700, Drummond Reed wrote: In other words, can a user just login to their IdP/i-broker, lthen follow “OpenID-enabled bookmarks” they have stored there to be directly logged in to sites where the user has logged in before? [...] (I suspect this may be part of the “bare message” thread but I confess as to not being fully up-to-speed on that issue.) Yes, I think that is the most compelling case for the "bare response" proposal. (although there are still unresolved conflicts in my head between that proposal and request nonces.) I don't recall offhand what the tally on that is. But if it doesn't pass, then no, this feature would not be in the OpenID 2.0 core spec, and thus may or may not work in the wild. One can imagine adding that on later, but if it doesn't go in core then it'll have to be something that RPs opt in to, and may not be supported universally. (which might work out okay.) ___ 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: Delegation Proposal Amendment
On 10/6/06, Granqvist, Hans <[EMAIL PROTECTED]> wrote: > Can you propose this in terms of diffs to the current draft so > it is glaringly obvious what the proposal means? Sure. > Also, I think this "diffs to current draft" can be most useful > for all proposals as it cuts through the various semantic > clouds we all have hanging over our heads ;) Do you mean literal Unix-style diffs or a human-readable set of changes to section numbers? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation Proposal Amendment
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 (http://openid.net/server/2.0), 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 =drummond.reed. Please confirm that you want to login to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel] Better still, this functionality is not limited to XRIs. RPs can apply it to any User just by prompting the user for a preferred Display Name along with their OpenID identifier. Then the RP can send the Display Name as the UPI string so the IdP can call the user by the same name. For example: Hello Drummond. Please confirm that you want to login to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel] So this boils down to a simple proposed amendment to your amendment: PROPOSED AMENDMENT: Add a third optional parameter, openid.display, the value of which is the UPI. The rules governing its use: 1) If the RP DOES NOT send openid.display, it defaults to openid.rp_user_id. (And by your amendment, if RP does not send openid.rp_user_id, then it defaults to openid.identity). 2) If the RP prompts the User for a Display Name for an OpenID identifier, the RP SHOULD set the value of openid.display to the UTF-8 encoded value of the display name string. 3) If the RP does not prompt the User for a Display Name (or if the User does not supply one), but if UPI is an i-name, the RP SHOULD send the i-name as the openid.display value. =Drummond
Re: [PROPOSAL] bare response / bare request
On Tue, 2006-10-03 at 19:42 -0700, Dick Hardt wrote: > On 2-Oct-06, at 12:34 PM, Kevin Turner wrote: > > On Sat, 2006-09-30 at 20:09 -0400, Dick Hardt wrote: > >> Motivating Use Case > >> > >> The IdP would like to allow the user to click a link on the IdP to > >> login to an RP. This requires a bare response to be able to be sent. > > > > How will RPs that customarily use a request nonce treat this? > > There will not be a request nonce -- could have the IdP say "none" Implications of this: 1) RPs must always accept messages without a request nonce. 2) RPs must always accept messages at the same return_to URL. which also means 3) RPs must never put nonces or (other tokens that will become invalid) in the return_to, because if they did the IdP would not recognize it as a nonce and remove it. Are these things all okay? I'm not sure if they really break stuff, but that puts a lot more restrictions on the return_to than I really feel comfortable with. And quite possibly takes a lot of the utility out of request nonces. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation Proposal Amendment
> Do you mean literal Unix-style diffs or a human-readable set > of changes to section numbers? I'd personally prefer the former, but I would settle for the latter. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] bare response / bare request
Well that is something that if the spec dictates where to place/format a request nonce, an IdP could recognize and remove it. I do agree though that it is getting close to having too many implications. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Turner Sent: Friday, October 06, 2006 3:25 PM To: specs@openid.net Subject: Re: [PROPOSAL] bare response / bare request On Tue, 2006-10-03 at 19:42 -0700, Dick Hardt wrote: > On 2-Oct-06, at 12:34 PM, Kevin Turner wrote: > > On Sat, 2006-09-30 at 20:09 -0400, Dick Hardt wrote: > >> Motivating Use Case > >> > >> The IdP would like to allow the user to click a link on the IdP to > >> login to an RP. This requires a bare response to be able to be sent. > > > > How will RPs that customarily use a request nonce treat this? > > There will not be a request nonce -- could have the IdP say "none" Implications of this: 1) RPs must always accept messages without a request nonce. 2) RPs must always accept messages at the same return_to URL. which also means 3) RPs must never put nonces or (other tokens that will become invalid) in the return_to, because if they did the IdP would not recognize it as a nonce and remove it. Are these things all okay? I'm not sure if they really break stuff, but that puts a lot more restrictions on the return_to than I really feel comfortable with. And quite possibly takes a lot of the utility out of request nonces. ___ 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
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. Translation: it would be really good for adoption. So if there's a way to design the protocol so that we can have OpenID-enabled bookmarks, let's choose that way unless everything else really breaks. =Drummond (playing OpenID marketer too) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Friday, October 06, 2006 4:12 PM To: Kevin Turner; specs@openid.net Subject: RE: [PROPOSAL] bare response / bare request Well that is something that if the spec dictates where to place/format a request nonce, an IdP could recognize and remove it. I do agree though that it is getting close to having too many implications. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Turner Sent: Friday, October 06, 2006 3:25 PM To: specs@openid.net Subject: Re: [PROPOSAL] bare response / bare request On Tue, 2006-10-03 at 19:42 -0700, Dick Hardt wrote: > On 2-Oct-06, at 12:34 PM, Kevin Turner wrote: > > On Sat, 2006-09-30 at 20:09 -0400, Dick Hardt wrote: > >> Motivating Use Case > >> > >> The IdP would like to allow the user to click a link on the IdP to > >> login to an RP. This requires a bare response to be able to be sent. > > > > How will RPs that customarily use a request nonce treat this? > > There will not be a request nonce -- could have the IdP say "none" Implications of this: 1) RPs must always accept messages without a request nonce. 2) RPs must always accept messages at the same return_to URL. which also means 3) RPs must never put nonces or (other tokens that will become invalid) in the return_to, because if they did the IdP would not recognize it as a nonce and remove it. Are these things all okay? I'm not sure if they really break stuff, but that puts a lot more restrictions on the return_to than I really feel comfortable with. And quite possibly takes a lot of the utility out of request nonces. ___ 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: Re[2]: Strong Authencation (was [PROPOSAL] authentication age
Thanks, Hans, I'm getting better educated on 2.0 every day. =Drummond -Original Message- From: Granqvist, Hans [mailto:[EMAIL PROTECTED] Sent: Friday, October 06, 2006 9:21 AM To: Drummond Reed; Chris Drake Cc: specs@openid.net Subject: RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age I think the 2.0 spec extension mechanism could handle signed credentials. For example, "credentials=" where is of a (string) format that contains a type + signature, say credentials=OATHVIP:WW91IGhhZCB0byBjaGVjaywgZGlkbid0IHlvdT8gOyk= The format could also further specify mechanism types, signer identity, and algorithm(s) used if those are not part of the definition of 'credentials'. Hans > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Drummond Reed > Sent: Thursday, October 05, 2006 2:26 PM > To: 'Chris Drake' > Cc: specs@openid.net > Subject: RE: Re[2]: Strong Authencation (was [PROPOSAL] > authentication age > > Chris, > > Great examples. Signed credentials makes lots of sense. > OpenID AuthN 2.0 doesn't handle them yet but I can completely > understand them in the roadmap. > > =Drummond > > -Original Message- > From: Chris Drake [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 05, 2006 10:51 AM > To: Drummond Reed > Cc: specs@openid.net > Subject: Re[2]: Strong Authencation (was [PROPOSAL] authentication age > > Hi Drummond, > > Example1: RSA would provide a signed response indicating that > the user correctly entered the SecurID token code. > > Example2: The RP would have the public key of the company > that supplies the fingerprint scanning hardware (although > some extra thought as to how a fingerprint ultimately matches > to an Identity is required, which will need an entirely > different information flow to Example1). > > Is Dick a vendor himself? he no doubt knows other ways. > > Kind Regards, > Chris Drake, > =1id.com > > > Friday, October 6, 2006, 3:19:44 AM, you wrote: > > DR> Dick, > > DR> You say, " The strong authentication will be supplied by a vendor > DR> that > has > DR> been certified to provide standardized levels of > authentication. The > DR> IdP will often NOT be the strong auth vendor." > > DR> Can you explain how this might work, i.e., how can the RP have a > DR> relationship directly with the strong auth vendor and not > the IdP? > DR> Would > the > DR> IdP be outsourcing authentication to the strong auth vendor? In > DR> which > case, > DR> isn't the strong auth vendor the IdP? > > DR> =Drummond > > DR> -Original Message- > DR> From: [EMAIL PROTECTED] > DR> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt > DR> Sent: Thursday, October 05, 2006 9:36 AM > DR> To: Gabe Wachob > DR> Cc: specs@openid.net > DR> Subject: Strong Authencation (was [PROPOSAL] authentication age > > DR> The vision I have is that strong authentication to your > IdP will be > DR> common in the future. > > DR> The strong authentication will be supplied by a vendor > that has been > DR> certified to provide standardized levels of > authentication. The IdP > DR> will often NOT be the strong auth vendor. > > DR> The RP will have a trust relationship with the vendor, likely > DR> through a vendor consortium that delegates to vendors that their > DR> product is certified, ie. the RP will not need to trust > each vendor, > DR> just the certification body. > > DR> I would hope that OpenID can be extended over time to be able to > DR> move around these types of strong auth assertions. > > DR> -- Dick > > > DR> On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote: > > >> Chris- > >>As someone who has recently come from working in the financial > >> sector (Visa), its clear that OpenID is NOT intended for > >> authentication where the *relying party* cares about how the > >> authentication is performed. > >> > >>At places like Visa and for home banking, this means > that OpenID, > >> without something more, is clearly a non-starter. These relying > >> parties want to know exactly how their users are being > authenticated > >> because their business is all about risk management and creating > >> business opportunities around very good knowledge of the > risk profile > >> of each transaction type. > >> > >>That all being said, I believe it should be possible to > layer on > >> OpenID a form of IDP control such that a relying party can > require a > >> certain class or group of IDPs be used when presenting > authentication > >> assertions to them. The actual *policy* for how these IDPs are > >> approved is probably orthogonal to the protocol spec, but "secure" > >> identification of those IDPs (relative to some trust root, > etc) could > >> probably be made into an extension usable for those > parties who want > >> it. > >> > >>My guess is that culturally, most people involved in OpenID have > >> *not* been interested in addressing these concerns. However,
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. 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? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Separate Public Identifier from IdP Identifier
Kevin Turner wrote: >>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? Sorry. That was sloppy. I did not intend there to be any change at all. By "Yadis discovery", I only meant to say that the RP would look for the relevant service element. My intention for this proposal has always been to not change anything at all beyond terminology, with the exception that openid:Delegate (which now has a new name) is required. I only changed it to required to reinforce the fact that it is distinct from the public identifier, and thus (hopefully) to make the spec easier to understand by removing a special case. ___ 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[2]: [PROPOSAL] bare response / bare request
KT> 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. KT> Okay Customer, if both websites and IdPs would love it, is it okay if KT> it's something that websites + IdPs can layer on top of the core? If KT> some sites chose not to, and the IdP said "login bookmark not available KT> for this site", would that be okay? Technically - the only thing we need is a mechanism for the IdP to find the RPs OpenID "bookmark entrance" - a hidden field in the original login should be sufficient: IdP can then save this URL in the users profile for them. Chris. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
