Hi Dick, Comments inline below:
On Jul 20, 2011, at 11:10 AM, Dick Hardt wrote: > > On 2011-07-20, at 9:09 AM, John Kemp wrote: > >> On Jul 20, 2011, at 12:05 AM, Manger, James H wrote: >> >>>>> As for one of the major advantages of BrowserID: it is a user-centric >>>>> architecture unlike OpenID Connect. >>> >>>> Can you explain what you mean by "user-centric" in this context? >>> >>> >>> With OAuth2 (and hence OpenID Connect, I assume) the RP needs to be >>> registered with the IdP. It is not user-centric because the user cannot >>> arbitrarily choose an IdP -- they can only choose an IdP with whom the RP >>> is registered, which may well mean only one of a handful of major IdPs. >> >> Oh - I guess I had thought from reading the protocol that I would be >> required either to choose my email provider as an IdP (only they can verify >> that I "own" that email address, and assert it reasonably to an RP) or to >> get browserid.org to verify and assert my email address "on behalf" of my >> email provider to RPs? >> >> I guess I can always assert my email address to an RP myself, and even >> create my own POP/SMTP server so that I can back up that assertion with the >> "verified email protocol" proposed by BrowserID? >> >> But I assume that the value of this protocol is not too different than that >> proposed value of OpenID (Connect); that is, an IdP will *assert* the email >> address of a user at the IdP to RPs, and that it will carry weight because >> of some relationship between the IdP and RP (either because the IdP Is >> Famous, or because there is a crypto-based relationship, either dynamic -- >> DH association a la OpenID, or static like the PKI-based solution possible >> in SAML for example). BrowserID seems to offer the same possibility - >> https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest#Recommended_public_key_discovery_mechanisms >> - that RPs will validate the IdPs signature over the assertion... > > > The user may (and should) have different email addresses. BrowserID enables > the user to choose which one to use at an RP. OpenID Connect will hand one or > them all over -- and you have to trust the OpenID Connect provider that the > email is truly yours unlike with BrowserID. As far as I understand the protocol written in the spec I linked to (see step 4 of https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest#Assertion_Verification), the identity assertion should be signed by an IdP - at least RPs are told that the signature over the assertion "must be verified with the public key contained in the certificate". > >> >>> BrowserID is user-centric in that the RP can verify the signature of >>> whichever email provider the user chooses. It doesn't rely on a prior >>> agreements between the RP and IdP. >> >> I agree with your specific statement - so I won't quibble over whether this >> is necessarily "user-centric" or not ;) > > I think that is one of the key aspects of user-centricity. The user is making > choices on which attributes to share. The user is determining "who" she wants > to be in a given RP context. Yes, I understand what you mean. I'm just personally not sure that BrowserID is really so much more "user-centric" in the way you mean than OpenID (Connect). Cheers, - John _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
