Mozilla BrowserID

Anthony Nadalin tonynad at microsoft.com
Wed Jul 20 17:44:10 UTC 2011


Once a curmudgeon always a curmudgeon!. We did conclude that the InforCard UX was far too complicated and that the user did not understand how to respond to all the choices and consent during a transaction. So does the user really have to be in the direct flow to have choice and consent? Authorization is consent and specific preferences on the service can serve choice, so the client has now had choice and consent.

-----Original Message-----
From: Dick Hardt [mailto:dick.hardt at gmail.com] 
Sent: Wednesday, July 20, 2011 10:17 AM
To: Anthony Nadalin
Cc: Manger, James H; OpenID Specs Mailing List
Subject: Re: Mozilla BrowserID

I would agree InfoCard failed. I would not agree that we can conclude the InfoCard UX failed. People understood the card metaphor and selecting them.

I think you are missing my point though -- the service model dispenses with the user once authorization has occurred. There is no opportunity for any UX that I have seen. Was that not clear from what I wrote Tony? ... or are you just being a curmudgeon? :)

-- Dick

On 2011-07-20, at 11:11 AM, Anthony Nadalin wrote:

> InfoCard UX failed, U-Prove UX failed these were far too complicated for the user, so same issue comes up in either service or user centric models.
> 
> -----Original Message-----
> From: Dick Hardt [mailto:dick.hardt at gmail.com] 
> Sent: Wednesday, July 20, 2011 9:08 AM
> To: Anthony Nadalin
> Cc: Manger, James H; OpenID Specs Mailing List
> Subject: Re: Mozilla BrowserID
> 
> um ... there have been numerous UX examples showing how the user can select what is shared
> 
> InfoCard had a selector, BrowserID has a selector, Sxipper had a selector ... there is no selection step in OpenID Connect except for deciding which button to click on at the start -- or which identifier to type into the box
> 
> On 2011-07-20, at 11:02 AM, Anthony Nadalin wrote:
> 
>> So the same significant disadvantages exist in user-centric also, as they have not been figured out
>> 
>> -----Original Message-----
>> From: openid-specs-bounces at lists.openid.net [mailto:openid-specs-bounces at lists.openid.net] On Behalf Of Dick Hardt
>> Sent: Wednesday, July 20, 2011 6:31 AM
>> To: Manger, James H
>> Cc: OpenID Specs Mailing List
>> Subject: Re: Mozilla BrowserID
>> 
>> John: A user-centric architecture has the user's agent in the middle of identity transactions. There are some pictures in the slides I show in my short presentation linked here:
>> 
>> http://dickhardt.org/2010/12/oidf-2010/
>> 
>> In OpenID Connect, the user gives authorizes the RP to call an API at the IdP to retrieve information about the user. I call this a service-centric model. There are a number of significant disadvantages of this model:
>> 
>> 1) there are unsolved UX challenges to the user seeing what identity data the RP will get from the IdP. 
>> 
>> 2) if the user has multiple equivalent attributes, there is no UX for asking the user which one to provide the RP, so either they are all provided, or just one. Eg. the user may have multiple postal addresses, and different ones will be appropriate for different RPs.
>> 
>> 3) No simple mechanism has been specified on how the IdP can share claims from 3rd parties. In a user-centric model, the user agent can pull claims from multiple parties to satisfy an identity request from the user.
>> 
>> James: OpenID Connect does have dynamic client spec:
>> 	http://openid.net/specs/openid-connect-registration-1_0.html
>> 
>> Time will tell if any IdP will support it for acquiring identity data. (for that matter, I have not yet seen any major IdP announce support for OpenID Connect)
>> 
>> The map that Nat created here:
>> 	http://openid.net/2011/07/15/current-map-for-openid-connect/
>> helps to navigate.
>> 
>> 
>> On 2011-07-19, at 11:05 PM, 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.
>>> 
>>> 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.
>>> 
>>> --
>>> James Manger
>> 
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 







More information about the specs mailing list