Connect spec updated

[Lukas Rosenstock]

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.
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?

Regards,
 Lukas

2010/5/19 David Recordon <recordond at gmail.com>

> 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
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
http://lukasrosenstock.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100519/23260027/attachment-0001.htm>