[Openid-specs-ab] Messages -15 RC: what to do malformed or ambiguous requests?
Michael.Jones at microsoft.com
Mon Jan 28 19:36:03 UTC 2013
I realize you're not trying to nickpick. Quite to the contrary - you're adding significant value with your observations. Keep it up! :)
I just filed this bug http://hg.openid.net/connect/issue/713/messages-basic-implicit-explicitly-require to address the requirement that the UserInfo endpoint always return the "sub" claim. As text was refactored, this was partially lost.
I also agree that the interpretation of the first example (response_type "token"), while reasonable, probably isn't made explicit in the specs. I've filed this bug http://hg.openid.net/connect/issue/714/review-text-specifying-response_type to track this and related response_type issues.
I've also reopened 671 for further review of the current text for this issue.
Thanks a bunch,
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Brian Campbell
Sent: Monday, January 28, 2013 10:23 AM
To: openid-connect-interop at googlegroups.com
Cc: <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Messages -15 RC: what to do malformed or ambiguous requests?
I think your second interpretation of the 3rd example is more consistent with what you've said previously about it. But neither is unreasonable, IMHO. I believe your interpretation of the 1st example is perfectly reasonable but I'd disagree that it's well defined. I don't see any text that directly associated the sub claim with the openid scope other than via indirectly thought the id token and requirements that the sub claim in the id token match the sub claim form the UserInfo endpoint. I'd forgotten about issue 671 but looking back at it reminded me that I think I disagree in principal on the implications of the decision made there. Also, all the text (https://bitbucket.org/openid/connect/commits/5aa754b1332d) that John wrote in resolving 671, including some that would seem to directly contradict your your interpretation of the 1st example, has been replaced or deleted by other checkins in the last week or so.
Anyway, I'm not trying to nitpick or argue with you about these (though I realize the last paragraph might read that way, it's not the intent) but the meta-point I do want to make is that I honestly don't think the spec is unambiguously clear on many of these scope/response_type combinations. And maybe that's okay. But if there are any security implications (seems like maybe the 1st example could lead to trouble but I dunno) or there are or will be any interop tests, it should probably be tightened up.
On Sun, Jan 27, 2013 at 7:53 PM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
Actually rereading this, the third example doesn't include the "openid" scope value, and so it's entirely outside the realm of what OpenID Connect specifies. It's just an OAuth 2.0 request - not an OpenID Connect request. The "profile" scope value is only meaningful in this case if the two participants agree what it means. It's meaning might have nothing to do with the OpenID Connect meaning of that value.
From: openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com> [mailto:openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>] On Behalf Of Mike Jones
Sent: Sunday, January 27, 2013 3:05 PM
To: openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>; <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Subject: RE: Messages -15 RC: what to do malformed or ambiguous requests?
Here's my take on the (good) questions that you raised, Brian...
This is meaningful and well-defined. It requests an access token for the OpenID UserInfo Endpoint but requests no ID Token. The "sub" claim must be made available at the UserInfo endpoint.
scope=openid profile email address
This is an error, because it requests that claims be returned via the UserInfo endpoint, but requests no access token by which to access those claims. John applied the fix to https://bitbucket.org/openid/connect/issue/671/ to make it clear that an error should be returned in this case. (Please review the text of the change. :))
Like the first example, this is well-defined.
From: openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com> [mailto:openid-connect-interop at googlegroups.com] On Behalf Of Brian Campbell
Sent: Friday, January 25, 2013 1:54 PM
To: <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>; openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>
Subject: Messages -15 RC: what to do malformed or ambiguous requests?
There are a number of possible combinations of parameters that seem (at least to me) like they might be considered malformed or ambiguous. A few examples are listed below but there are other combinations, usually where what's requested by the response type is somehow misaligned with what's requested via scope. The messages spec gives some guidance, for example around scope in 2.4 and the openid scope value in 2.4 but it's still not entirely clear what the expected behavior is for these kind of things. I know this question, or variations on it, have come up before but I don't know that an answer was ever settled on. And it's still not clear to me from reading RC/-15.
Is there a general expectation of behavior around this kind of thing? Should the AS just make a best effort? Or should it return errors to the client? Or something else? Even if the specs decide to leave it entirely up to the implementations, I think it'd be useful to say as much.
Some example combinations of response_type and scope that I don't know what to do with:
scope=openid profile email address
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab