On Wed, May 19, 2010 at 3:02 AM, Lukas Rosenstock <[email protected]>wrote:
> Hi David, hi everyone, > > hope you had a great IIW! > I want to appreciate your work with OpenID Connect, it's a good proposal > and a base to move ahead with OpenID. Merging OpenID and OAuth is a great > idea because it eliminates implementing two protocols, because practically > OpenID just adds basic identity functions and discovery on top of OAuth. > > Regarding your changes: > If I have understood correctly, the user can enter anything (Profile or > Provider URL or E-Mail through Webfinger) to start the flow because this > information is just used for discovery of the OAuth endpoint. > The actual user identifier is returned by the OAuth flow and this > identifier must be an HTTPS URL and this HTTPS URL must return the basic > information about the user in JSON. So OpenIDs are now URLs which are not > intended for human consumption to for the API. > Correct. Unlike OpenID 1.0 and 2.0, user identifiers are no longer designed for human consumption. Rather the client also gets one or more profile URLs which are designed for human consumption. > Now, this endpoint would be a great place to allow for discovery of further > information about the user, for example a Portable Contacts endpoint, a feed > (RSS/Atom) or a FOAF file. Therefore I would suggest making this endpoint > return meta information in XRD or JRD or a similar format which allows for > links into further information and endpoints for the assured user, rather > just a plain basic profile JSON. > What do you think? > Completely agreed. We need to sort out the schema of the returned JSON document. I think JRD ( http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/) gets us most of the way there including the ability to link to Portable Contacts and other types of API endpoints. --David Regards, > Lukas > > 2010/5/19 David Recordon <[email protected]> > >> Coming out of some conversations at IIW today I've made some changes to >> the proposal. Patch is attached, but they are: >> - Allow passing in `user_id` as a hint when not using immediate mode in >> the request. >> - Continue to allow users to enter URLs, email addresses, and click >> buttons but the returned user identifier must be a HTTPS URI. >> - Include the expiration time within the signature. >> - Clarify how you verify if the token endpoint is authoritative for a >> given user identifier. >> - Simplify discovery by removing LRDD and using host-meta to determine >> the server token endpoint on a per domain (or sub-domain) basis. We're >> having a hard time finding use cases of running multiple different OpenID >> servers per domain. >> - Remove the separate user info API endpoint and instead make the user >> identifiers a protected resource. Fetch the user identifier with an access >> token and it returns basic profile information as well as if the access >> token was issued by that specific user. >> >> Thanks for all of the feedback and support both virtually and in person! >> I'm planning to move this proposal into GitHub next week (and work with Eran >> to actually format it like a spec) so that changes are easier to keep track >> of. >> >> --David >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> > > > -- > http://lukasrosenstock.net/ > > _______________________________________________ > 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
