[Openid-specs-ab] Messages -15 RC: what to do malformed or ambiguous requests?

Brian Campbell bcampbell at pingidentity.com
Mon Jan 28 18:23:04 UTC 2013


Thanks Mike.

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>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.****
>
> ** **
>
>                                                             Best wishes,**
> **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* 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; <
> 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…****
>
>
>             response_type=token
>             scope=openid****
>
> 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.****
>
>
>             response_type=id_token
>             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. J)****
>
>
>             response_type=code
>             scope=profile****
>
> ** **
>
> Like the first example, this is well-defined.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* openid-connect-interop at googlegroups.com [
> mailto:openid-connect-interop at googlegroups.com<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>;
> 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:****
>
>
> response_type=token
> scope=openid
>
> response_type=id_token
> scope=openid profile email address
>
> response_type=code
> scope=profile****
>
> --
>
>  ****
>
> --
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130128/fe8747ef/attachment-0001.html>


More information about the Openid-specs-ab mailing list