Include user profile information in response

indieweb / indieauth

IndieAuth.net website code and IndieAuth Specification

52 stars 7 forks source link

Include user profile information in response #41

Closed aaronpk closed 3 years ago

aaronpk commented 3 years ago

There are some experiments of returning profile information in exchange for an authorization code in the response directly, simplifying the development of clients.

e.g.

{
  "me":"https://aaronparecki.com/",
  "profile": { 
    "type": "card",
    "name": "Aaron Parecki",
    "url": "https://aaronparecki.com/",
    "photo": "https://aaronparecki.com/images/profile.jpg"
  }
}

This can be returned whether or not an access token is also returned.

dshanske commented 3 years ago

Related #31

manton commented 3 years ago

Micro.blog now includes profile too.

tbhb commented 3 years ago

Implemented now in Singulus for GET /indieauth/token, POST /indieauth/token, and POST /indieauth/authorize https://github.com/craftyphotons/singulus/commit/d1cf38ddb0bbad08d2240a00f10a077d00738d2c

aaronpk commented 3 years ago

This was discussed at the IndieAuth Popup Session, and the outcome of the discussion was:

General support for this feature
The profile data is not guaranteed to be verified in any way. It is what the user chooses to provide to the application for display purposes only. Definition of profile data and its authoritative nature has to be added to the spec.
Should be returned only when requested by the profile scope
Add email property and scope
Clarify the purpose of this which is informational to the application, not anything authoritative about the user and must not be used to identify users (e.g. making any decisions based on the email returned can lead to security holes)
Implementing this is optional

aaronpk commented 3 years ago

I'm starting to write the text for this, and realizing now that by not actually tying this vocabulary to jf2 or mf2, the type: card property is kind of redundant. The data here will always be from the h-card vocabulary anyway, so there doesn't seem to be any reason to include that property. Anyone opposed to just leaving that out since the IndieAuth spec is going to be defining the specific properties to be returned in the object anyway?