Still editing, but this is what the core is looking like as of now. <div><br></div><div>=nat<br><br><div class="gmail_quote">On Fri, May 13, 2011 at 1:50 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Mike, thanks for this work.<br>
<br>
I am now anxious to see the 'core' rewriting to make it more a wrapper<br>
around OAuth2.<br>
<div><div></div><div class="h5"><br>
On Thu, May 12, 2011 at 09:46, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:<br>
> As promised, Nat, John, and I spent time at the European Identity Conference<br>
> (EIC) in Munich turning the decisions made at IIW into actual specification<br>
> language. The write-up for the OpenID Connect response objects structures<br>
> follows.<br>
><br>
><br>
><br>
> -- Mike<br>
><br>
><br>
><br>
> OpenID Connect uses two kinds of responses: The OpenID Token, which is<br>
> returned directly, and the UserInfo Endpoint values, which are retrieved<br>
> from the UserInfo Endpoint API.<br>
><br>
><br>
><br>
> The OpenID Token is a JWT, containing information about the identity of the<br>
> user, session information, and information about the authentication that<br>
> occurred. The UserInfo Endpoint value is a set of claims about the user.<br>
><br>
><br>
><br>
> In the default case, the UserInfo Endpoint claims are returned in the<br>
> response body as a bare JSON object. All implementations MUST implement<br>
> this functionality.<br>
><br>
><br>
><br>
> Claims MAY also be returned as a JWT, which enables them to be signed and/or<br>
> encrypted. In this case, the JWT (which utilizes a base64url encoded<br>
> representation) is returned in the message body. The two cases can be<br>
> easily distinguished since in the default case, the first character of the<br>
> response will always be "{", whereas when a JWT is returned, the first<br>
> character will always be one of the 64 base64url encoding characters.<br>
> Implementing support for the UserInfo Endpoint returning claims in a JWT is<br>
> OPTIONAL.<br>
><br>
><br>
><br>
> An example claims object returned from the UserInfo Endpoint is as follows:<br>
><br>
><br>
><br>
> {<br>
><br>
> "name": {"givenName": "Jane", "familyName": "Doe"}<br>
><br>
> "displayName": "Jane Doe",<br>
><br>
> "emails": [{"value": "<a href="mailto:janedoe@example.com">janedoe@example.com</a>", "primary": true, "verified":<br>
> true}],<br>
><br>
> "photos": [{"value": "<a href="https://example.com/profiles/janedoe/photo.jpg" target="_blank">https://example.com/profiles/janedoe/photo.jpg</a>",<br>
> "type": "photo"},<br>
><br>
> {"value": "<a href="https://example.com/profiles/janedoe/thumb.jpg" target="_blank">https://example.com/profiles/janedoe/thumb.jpg</a>",<br>
> "type": "thumbnail"}]<br>
><br>
> }<br>
><br>
><br>
><br>
> Claims can be represented in one of three forms:<br>
><br>
> - Normal claims: Claims directly asserted by the IdP<br>
><br>
> - Aggregated claims: Claims asserted by a claims provider other than the<br>
> IdP that are returned by the IdP<br>
><br>
> - Distributed claims: Claims asserted by a claims provider other than the<br>
> IdP, where the IdP returns references enabling them to be retrieved<br>
><br>
><br>
><br>
> Support for the normal claims representation is REQUIRED. Support for<br>
> aggregated and distributed claims is OPTIONAL.<br>
><br>
><br>
><br>
> Normal claims are represented as members of the claims object, with the<br>
> claim name being the member name, and the claim value being the member<br>
> value. The claims in the example above are all normal claims.<br>
><br>
><br>
><br>
> Both aggregated claims and distributed claims are represented using two<br>
> distinguished members within the claims object. These members are:<br>
><br>
> "_claim_names": A JSON object whose member names are additional claim<br>
> names for either aggregated or distributed claims and whose values specify<br>
> claim sources from which the claim values can be retrieved. These values<br>
> are indexes into the "_claim_sources" member.<br>
><br>
> "_claim_sources": A JSON object whose member names are referenced from<br>
> the "_claim_names" member values, and whose values either contain sets of<br>
> aggregated claims or reference locations from which sets of distributed<br>
> claims can be retrieved.<br>
><br>
><br>
><br>
> An example using these members is as follows:<br>
><br>
><br>
><br>
> {<br>
><br>
> "name": {"givenName": "Jane", "familyName": "Doe"}<br>
><br>
> "displayName": "Jane Doe",<br>
><br>
> "_claim_names":<br>
><br>
> {<br>
><br>
> "birthday": "src1",<br>
><br>
> "eyeColor": "src1",<br>
><br>
> "paymentInfo": "src2",<br>
><br>
> "shippingAddress": "src2",<br>
><br>
> "creditScore": "src3"<br>
><br>
> }<br>
><br>
> "_claim_sources":<br>
><br>
> {<br>
><br>
> "src1": {"JWT": "JWT_hdr.JWT_claims.JWT_crypto"},<br>
><br>
> "src2": {"endpoint": "<a href="https://merchant.example.com/claimsource" target="_blank">https://merchant.example.com/claimsource</a>"}<br>
><br>
> "src3": {"endpoint": "<a href="https://creditagency.example.com/claimshere" target="_blank">https://creditagency.example.com/claimshere</a>",<br>
> "access_token": "string"}<br>
><br>
> }<br>
><br>
> }<br>
><br>
><br>
><br>
> In this example, the "name" and "displayName" claims are directly asserted<br>
> by the IdP, the "birthday" and "eyeColor" come from a JWT containing these<br>
> aggregated claims (perhaps from a department of motor vehicles), the<br>
> "paymentInfo" and "shippingAddress" claims can be retrieved from the named<br>
> merchant (which may require user authentication at retrieval time), and the<br>
> "creditScore" claim can be retrieved from the named credit agency using the<br>
> provided access token.<br>
><br>
><br>
><br>
> The "_claim_sources" member values are JSON objects with one of two formats:<br>
><br>
><br>
><br>
> 1. For aggregated claims, a "_claim_sources" value is a JSON object with<br>
> these members:<br>
><br>
> "JWT": "JWT value" (REQUIRED) - MUST contain the claims to be<br>
> retrieved from that claim source, as listed in the associated "_claim_names"<br>
> list<br>
><br>
> Other members MAY be present, if understood by both parties<br>
><br>
><br>
><br>
> 2. For distributed claims, a "_claim_sources" value is a JSON object with<br>
> these members:<br>
><br>
> "endpoint": "Endpoint URL value" (REQUIRED) - MUST be a<br>
> source of the claims to be retrieved from that claim source, as listed in<br>
> the associated "_claim_names" list. This URL is for an OAuth 2.0 resource<br>
> endpoint. The claims MUST be returned as a JWT.<br>
><br>
> "access_token": "OAUTH2 access token" (OPTIONAL) - Access<br>
> token enabling retrieval of the claims from the URL by using the OAuth 2.0<br>
> BEARER scheme. Claims SHOULD be requested using the Authorization request<br>
> header field and claims sources MUST support this method.<br>
><br>
> Other members MAY be present, if understood by both parties<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
--Breno<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div>