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:[email protected]] > 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: [email protected] >> [mailto:[email protected]] 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 >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> >> > > > > > _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
