[Openid-specs-ab] OpenID UserInfo Endpoint notes

[Nat Sakimura]

It is hard to close on what should be included in UserInfo if we start
expanding.
In the interest of the time that we want to close this round of ABC spec,
may I suggest that we stick to the minimum set like SREG?
Anything other than that should go to the extended list of claims.
I think that was the conclusion of the Feb. F2F.

For May 3 session at IIW, I would interpret that there were desires to
have more generalized claims in the floor.
We should do that in the companion spec that can come later,
which utilize generalized claims request response syntax.

=nat

On Wed, May 4, 2011 at 9:21 AM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  Session:  OpenID UserInfo Endpoint
>
> Organizers:  Nat Sakimura
>
> When:  May 3, 2011, 3:00 (Session 4), Room E
>
> Note Taker:  Mike Jones
>
>
>
> Nat displayed the notes from the working group meeting at RSA containing
> notes on the UserInfo endpoint.  Those notes were:
>
>
>
>     UserInfo endpoint
>
>                Basically what registration widget would need
>
>                Facebook UserInfo
>
>                               full_name, first_name, last_name (no display
> name)
>
>                               birthday
>
>                               e-mail (verified)
>
>                               gender
>
>                               location - array of name and ID
>
>                               link(s)
>
>                               hometown
>
>                               bio
>
>                               work
>
>                               sports
>
>                               interested_in
>
>                               meeting_for
>
>                               significant_other
>
>
>
>                               religion                political
>
>                               timezone
>
>                               locale
>
>                               languages - array of id, location
>
>                               website
>
>                               update_time
>
>                               verified
>
>                Can also ask for
>
>                               captcha
>
>                               password
>
>                Facebook phone number retrieval in a specialized scope
>
>                Want
>
>                               display_name
>
>                               user_id
>
>                               e-mail verification status
>
>                               locale
>
>                               image
>
>                               client_id
>
>                               last_auth_time or issued_at
>
>                David also has
>
>                               profile_url
>
>                               domain
>
>                               OpenID2
>
>                UserInfo provides a default set of claims
>
>                Other claims can be asked for
>
>                Use short names in JSON representation
>
>                High level goal to make RP registration easy
>
>                Can also agree on additional scopes (such as "address")
>
>                No_pii scope?
>
>                Can disable default, ask for specific fields
>
>                Space delimited scope identifiers in OAuth2 scope parameter
>
>                OpenID scope
>
>                We discussed whether authentication context parameters
> should be scopes
>
>
>
>                first_name#ja_homi_JP - can put in scope
>
>
>
> We started down the road of discussing a general claims mechanism and
> agreed that that is a different discussion for a different session.
>
>
>
> We debated how granular we want the information provided to be and
> permissioning issues.
>
> Paul Madsen raised the question of whether all the claims must be sent.
>
> We agreed that the permissioning and business models are out of scope for
> this session.
>
>
>
> John Bradley asked whether the UserInfo endpoint should always contain the
> userid.
>
> Phil Hunt asked what security context the request for the UserInfo data
> occurs in.  In particular, does the IdP know to what RP the data is being
> released to?  In general, the answer is “yes”.
>
>
>
> Justin Richter asked whether we can use Portable Contacts data structures.
>
> Chuck Mortimore said that JanRain has mapped about 20 providers’ user info
> data into PoCo data structures.
>
>
>
> Breno made the point that the baseline needs to be simple and predictable.
>
> The business goal is to provide an open equivalent to Facebook Connect.
>
>
>
> *We didn’t get to actually discussing the specific claims list in the
> default set.*  We agreed that we need another session just to go over the
> set of claims in the default set.
>
>
>
> Breno (in closing) – this is the absolute minimum set to minimally supply a
> majority of use cases
>
>                Display Name
>
>                Full Name
>
>                Photo
>
>                e-Mail Address
>
>                Profile URL
>
>                Data of Birth
>
> It’s the lightweight registration widget that we need to implement.
>
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110504/f5257f47/attachment.html>