On 2011-07-20, at 10:28 AM, John Kemp wrote: > Hi Dick, > > Comments inline below:
responses inline below them :) >>>> 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". The IdP is the mail provider. browserid.org is a stop gap provider to fall back on if your mail provider does not support BrowserID > >> >>> >>>> 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). The flow is moving from my agent (the browser) to the RP rather than from the IdP to the RP. _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
