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

John Bradley ve7jtb at ve7jtb.com
Sat Feb 2 02:36:05 UTC 2013


Without violating OAuth we can't eliminate the required query parameters, only verify the OAuth parameters against the ones in the request object.

Are you suggesting that all the top level elements from a request object also be valid as query parameters?


On 2013-02-01, at 10:52 PM, Breno de Medeiros <breno at google.com> wrote:

> As I understand, the intent of the request document is to enable signature.
> 
> I think it'd be far simpler if the request object simply specified how
> to replace all parameters of a request with the request object and how
> to parse and verify.
> 
> Claims could then be a separable part that is not MTI
> 
> In addition, all current parameters that are defined as MTI for the
> request object could just be made top-level parameters that are
> mandatory to implement. The fact that they are signed or not is really
> orthogonal, it's perfectly possible to use any and either of these
> parameters in an unsigned context.
> 
> 
> On Fri, Feb 1, 2013 at 3:55 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>> I intentionally left out “acr” because it’s a request for a specific claim.
>> If people don’t want to support requests for specific claims, the ability to
>> use “acr” in an effective manner would go away.  On the other hand, I
>> believe that it is reasonable to require support for fine-grained claims
>> requests in any profile that’s using Authentication Contexts.
>> 
>> 
>> 
>> There’s another thread on this, but unless people disagree, I think we
>> should add to the specs that “preferred_locales” should be applied to the
>> user interface as well.
>> 
>> 
>> 
>>                                                                -- Mike
>> 
>> 
>> 
>> From: John Bradley [mailto:ve7jtb at ve7jtb.com]
>> Sent: Friday, February 01, 2013 3:51 PM
>> To: Mike Jones
>> Cc: Tim Bray; openid-specs-ab at lists.openid.net
>> Subject: Re: [Openid-specs-ab] Possible MTI fallback position for OpenID
>> Request Object
>> 
>> 
>> 
>> Mike you seem to have dropped acr in this example.
>> 
>> 
>> 
>> While I could live with this I think the acr and auth_time claims in the
>> id_token should be called out they are not generic claims delivered from the
>> user_info endpoint.
>> 
>> 
>> 
>> I could probably live with this assuming that any OP supporting any
>> significant enterprise or higher LoA applications would support them.
>> 
>> 
>> 
>> That sort of leaves three buckets in my mind.
>> 
>> 
>> 
>> The ones you have in green as MUST.
>> 
>> acr and auth_time in the id_token as SHOULD for everyone and MUST for higher
>> levels of trust.
>> 
>> The fine grand claims a should for everyone and a MUST in some jurisdictions
>> for privacy.
>> 
>> 
>> 
>> I can probably live with those two elements being moved up.
>> 
>> max_age is a processing request and not a claim, the claim typically in the
>> response is auth_time.   If we move it up and say that if max_age is
>> requested auth_time SHOULD be included as a claim in the id_token I would be
>> OK with that.
>> 
>> 
>> 
>> preferred_locales is also more of a processing request that in principal
>> applies to both claims in the id_token and user_info endpoint.  so I can see
>> an argument for moving it up.
>> 
>> 
>> 
>> One thing we may be missing thinking about this is a UI language hint.  I
>> know it is something some governments (Canada, Belgium etc require)  I know
>> we have browser preferences that are supposed to do this but are largely
>> ignored as they are us_eng 99% of the time according to people I have talked
>> to at google about why they ignore them and change my UI to Spanish all the
>> time.
>> 
>> 
>> 
>> I don't know if there is a implication that preferred_locales affects the
>> UI, but if people are thinking that we don't state it anyplace.
>> 
>> 
>> 
>> John B.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 2013-02-01, at 2:58 PM, 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
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
> 
> 
> 
> -- 
> --Breno



More information about the Openid-specs-ab mailing list