[Openid-specs-ab] Possible MTI fallback position for OpenID Request Object

Mike Jones Michael.Jones at microsoft.com
Fri Feb 1 23:07:22 UTC 2013


The only other thing I'll add is to be sure to use the HTML version of my message, because the colors in it are important.  Your mail agent at textuality appears to have converted the HTML to raw text.

				-- Mike

-----Original Message-----
From: Tim Bray [mailto:tbray at textuality.com] 
Sent: Friday, February 01, 2013 2:13 PM
To: Mike Jones
Cc: openid-specs-ab at lists.openid.net
Subject: Re: Possible MTI fallback position for OpenID Request Object

This seems to be worth investing discussion in. Does anyone but Mike have any input before I get our implementors chewing it over? -T

On Fri, Feb 1, 2013 at 9:58 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> Using real syntax to hopefully make things clear, the fallback 
> position for discussion is that OPs would be required to understand 
> request objects like this one, in which the request parameters are 
> sent in the request object, rather than as HTTP query parameters:
>
>
>
> {
>
> "response_type": "code id_token",
>
> "client_id": "s6BhdRkqt3",
>
> "redirect_uri": "https://client.example.org/cb",
>
> "scope": "openid",
>
> "state": "af0ifjsldkj",
>
> "login_hint": "janedoe at example.org",
>
> }
>
>
>
> OPs would be required to understand and act upon the "max_age" 
> parameter and should also understand and process the "preferred_locales" parameter:
>
>
>
> {
>
> "userinfo":
>
>   {
>
>    "preferred_locales": ["en-US", "fr-CA"]
>
>   },
>
> "id_token":
>
>   {
>
>    "max_age": 86400
>
>   }
>
> }
>
>
>
> They would *not* be required to understand requests for specific 
> claims, such as:
>
>
>
> {
>
> "userinfo":
>
>   {
>
>    "claims":
>
>      {
>
>       "group_memberships": null,
>
>       "name": {"essential": true},
>
>       "nickname": null,
>
>       "email": {"essential": true},
>
>       "email_verified": {"essential": true},
>
>       "picture": null,
>
>       "favorite_color": null,
>
>       "eye_color": null
>
>      }
>
>   },
>
> "id_token":
>
>   {
>
>    "claims":
>
>     {
>
>      "auth_time": {"essential": true},
>
>      "acr": { "values":["2"] }
>
>     }
>
>   }
>
> }
>
>
>
> Putting it all together into a request object using essentially every 
> type of request parameter, the green parts would need to be understood 
> and the red parts would not:
>
>
>
> {
>
> "response_type": "code id_token",
>
> "client_id": "s6BhdRkqt3",
>
> "redirect_uri": "https://client.example.org/cb",
>
> "scope": "openid",
>
> "state": "af0ifjsldkj",
>
> "login_hint": "janedoe at example.org",
>
> "userinfo":
>
>   {
>
>    "preferred_locales": ["en-US", "fr-CA"],
>
>    "claims":
>
>      {
>
>       "group_memberships": null,
>
>       "name": {"essential": true},
>
>       "nickname": null,
>
>       "email": {"essential": true},
>
>       "email_verified": {"essential": true},
>
>       "picture": null,
>
>       "favorite_color": null,
>
>       "eye_color": null
>
>      }
>
>   },
>
> "id_token":
>
>   {
>
>    "max_age": 86400,
>
>    "claims":
>
>     {
>
>      "auth_time": {"essential": true},
>
>      "acr": { "values":["2"] }
>
>     }
>
>   }
>
> }
>
>
>
> Having reviewed this, we might also choose to simplify this to the 
> following - moving the "preferred_locales" and "max_age" parameters to 
> the top level as follows.  I'll send a separate note about this.  Then 
> the example would become the simpler:
>
>
>
> {
>
> "response_type": "code id_token",
>
> "client_id": "s6BhdRkqt3",
>
> "redirect_uri": "https://client.example.org/cb",
>
> "scope": "openid",
>
> "state": "af0ifjsldkj",
>
> "login_hint": "janedoe at example.org",
>
> "preferred_locales": "en-US fr-CA",
>
> "max_age": 86400,
>
> "userinfo":
>
>   {
>
>    "preferred_locales": ["en-US", "fr-CA"],
>
>    "claims":
>
>      {
>
>       "group_memberships": null,
>
>       "name": {"essential": true},
>
>       "nickname": null,
>
>       "email": {"essential": true},
>
>       "email_verified": {"essential": true},
>
>       "picture": null,
>
>       "favorite_color": null,
>
>       "eye_color": null
>
>      }
>
>   },
>
> "id_token":
>
>   {
>
>    "claims":
>
>     {
>
>      "auth_time": {"essential": true},
>
>      "acr": { "values":["2"] }
>
>     }
>
>   }
>
> }
>
>
>
> Hope this makes things concrete so that you can have a good discussion 
> with your engineering team.
>
>
>
>                                                             -- Mike
>
>
>
> -----Original Message-----
> From: Tim Bray [mailto:tbray at textuality.com]
> Sent: Friday, February 01, 2013 8:09 AM
> To: Mike Jones
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: Possible MTI fallback position for OpenID Request Object
>
>
>
> On Thu, Jan 31, 2013 at 4:54 PM, Mike Jones 
> <Michael.Jones at microsoft.com>
> wrote:
>
>
>
>> As discussed on today's call, it does several related things:
>
>
>
> Actually, part of the gripe is that the things it does are not 
> strongly/clearly related.
>
>
>
>> The primary thing that some people on the call seemed to feel should
>
>> not be Mandatory to Implement (MTI) functionality is having to 
>> respond
>
>> to requests for specific individual claims.
>
>
>
> Just to be clear: my engineering group wasn't objecting to any one 
> component in particular, just not wanting to take on the scaling and 
> UX consequences of the whole package of fish-and-bicycles as specified 
> in the current messages draft, when we we think we can build a 
> perfectly satisfactory and usable Internet-scale identity system without Request Objects.
>
>
>
>> In summary the, middle ground that I'd like people to discuss is:
>
>>   - Parsing OpenID Request Object MTI
>
>>   - Using request parameters contained in Request Object MTI
>
>>   - Supporting "preferred_locales" and "max_age" parameters MTI
>
>>   - Supporting "claims" fields OPTIONAL
>
>>   - If "claims" fields not supported, the claims returned would be 
>> determined by the OP
>
>>   - It would be discoverable whether "claims" is supported by an OP
>
>>   - Supporting "request_file" OPTIONAL
>
>>   - It would be discoverable whether "request_file" is supported
>
>>   - If "request_file" is not supported, the claims returned would be
>
>> determined by the OP
>
>
>
> I'm not sure I understand your 2nd bullet point, "request parameters".
>
> Maybe a pointer into section 2.1.1.1 would help?
>
>
>
> But here's what I think you meant.  A conforming implementation would 
> be required to:
>
>
>
> - parse the request object
>
> - understand and comply with:
>
> -- request_object['userinfo']['preferred_locales']
>
> -- request_object['id_token']['sub']
>
> -- request_object['id_token']['auth_time']
>
> -- request_object['id_token']['max_age']
>
> -- request_object['id_token']['acr']
>
> - everything else can be ignored
>
>
>
> I'll be honest; this seems like a bit of an uphill struggle.  But 
> before I take this to the guys, is my understanding of what you're proposing correct?
>
>
>
> -Tim


More information about the Openid-specs-ab mailing list