User info end point of Open ID ABC
Session Topic: OpenID User Info Endpoint (T4E)
Convener: Nat Sakimura
Notes-taker(s): Mike Jones
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
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)
- e-mail (verified)
- location - array of name and ID
- religion political
- languages - array of id, location
- Can also ask for
- Facebook phone number retrieval in a specialized scope
- e-mail verification status
- last_auth_time or issued_at
- David also has
- 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
- e-Mail Address
- Profile URL
- Data of Birth
It’s the lightweight registration widget that we need to implement. .