search

KantaraInitiative / wg-uma

This is the repository of all specifications related to the User Managed Access Group
http://kantarainitiative.org/confluence/display/uma/
Other
27 stars 21 forks source link

UMA should not presume to know when scope is not an error #347

Closed mrpotes closed 6 years ago

mrpotes commented 6 years ago

In section 3.3.4, the following is noted:

It is not an error for the client to have requested a scope for which it did not pre-register because RequestedScopes might include that same scope, requested on the client's behalf by the resource server when obtaining the permission ticket.

It does not seem possible for UMA to say definitively that it "is not an error" - in many cases this may be true, but there may be some deployments of UMA (say, in the military/intelligence community) in which any Client that attempts to request a scope that it is not registered for does require an invalid_scope error response. It should be up to the AS whether this is an error condition or not. Suggest the sentence is reworded to begin It may not be an error for...

ciseng commented 6 years ago

Not sure. The note is covering the case where a scope is requested by a client and not pre-registered but also exists in the permission ticket obtained from the resource server. The scope is included in the RequestedScopes only because it is in the permission ticket. Otherwise, it would not be included. So, the assessment can continue with this scope included. What would returning error in this case serve? Educating the client not to include this particular scope in its request?

In the case the scope was not included in the permission ticket then assessment still continues with client scopes that were pre-registered + permission ticket scopes. And yes, client may get a token that it does not contain all it asked for. In this case, I remember discussing whether to inform the client, and deciding not to do so... This part maybe clarified in the document that the client may not get a token with the scopes it requested (note this is different than partial token case).

mrpotes commented 6 years ago

I'm not saying that that isn't likely to be the case most of the time, I'm saying that I can envisage cases where an AS may want to do so, and we should relax our language a bit to permit it to do so. Given we haven't gone as far as to say "the authorization server MUST NOT return an error...", it does not seem unreasonable to do so.

On 2 Aug 2017 11:53, "ciseng" notifications@github.com wrote:

Not sure. The note is covering the case where a scope is requested by a client and not pre-registered but also exists in the permission ticket obtained from the resource server. The scope is includes in the RequestedScopes only because it is in the permission ticket. Otherwise, it would not be included. So, the assessment can continue with this scope included. What would returning error in this case serve? Educating the client not to include this particular scope in its request?

In the case, the scope was not included in the permission ticket then assessment still continues with pre-registered scopes + permission ticket scopes. And yes, client may get a token that it does not contain all it asked for. In this case, I remember discussing whether to inform the client, and deciding not to do so... This part maybe clarified in the document that the client may not get a token with the scopes it requested (note this is different than partial token case).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/wg-uma/issues/347#issuecomment-319625905, or mute the thread https://github.com/notifications/unsubscribe-auth/AA6kNu9y4TGaXJZCpYYL0DMwTli-m8rpks5sUEchgaJpZM4Omp01 .

ciseng commented 6 years ago

I understand your point. I think, we should not introduce “may” to the language what conditions we consider an error. What we can do is to have language that describes what the AS MAY/MUST/SHOULD do in this case. I am only slightly differing from your proposition: “It is not an error but AS MAY do X under a circumstance Y."

jwilleke commented 6 years ago

As some references to other similar? conditions:

OAuth " authorization server MAY fully or partially ignore the scope requested by the client based on the authorization server policy or the resource owner's instructions." and: Invalid_scope error implies the requested "scope is invalid, unknown, or malformed".

-- -jim Jim Willeke

On Wed, Aug 2, 2017 at 6:47 AM, ciseng notifications@github.com wrote:

I understand your point. I think, we should not introduce “may” to the language what conditions we consider an error. What we can do is to have language that describes what the AS MAY/MUST/SHOULD do in this case. I am only slightly differing from your proposition: “It is not an error but AS MAY do X under a circumstance Y."

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/wg-uma/issues/347#issuecomment-319637595, or mute the thread https://github.com/notifications/unsubscribe-auth/ADcvsO8_WDFyEhWg4mLFyg8IkIr7RAZhks5sUFO7gaJpZM4Omp01 .

xmlgrrl commented 6 years ago

Thanks to Jim for the OAuth context.

We thought we were explicitly ruling out an error with the wording we chose, but I guess it's too ambiguous. We should not say merely "It is not an error" but, I think, rather one of the following:

If we like Option 2 or Option 3 (I think Option 3 is probably going too far but listed it for completeness), we could potentially choose invalid_scope. That would overload it compared to not only its straight OAuth usage but also our usage in Grant Sec 3.3.6:

"At least one of the scopes included in the request does not match an available scope for any of the resources associated with requested permissions for the permission ticket provided by the client. The authorization server responds with the HTTP 400 (Bad Request) status code."

But maybe that makes sense.

mrpotes commented 6 years ago

For me, Option 2 is the only one that makes sense because I don't believe that we can always assume that a scope that is not pre-registered is either never (option 1) or always (option 3) an error.

On 7 August 2017 at 06:08, Eve Maler notifications@github.com wrote:

Thanks to Jim for the OAuth context.

We thought we were explicitly ruling out an error with the wording we chose, but I guess it's too ambiguous. We should not say merely "It is not an error" but, I think, rather one of the following:

  • Option 1: If the client requests a scope for which it has not pre-registered, it is not an error (... rest of rationale ...). The authorization server MUST NOT return an error for this reason.
  • Option 2: It might not be an error if the client requests a scope for which it has not pre-registered because (... rest of rationale ...). Alternatively, the authorization server MAY return (some error to be defined/chosen).
  • Option 3: If the client requests a scope for which it has not pre-registered, the authorization server MUST return (some error to be defined/chosen).

If we like Option 2 or Option 3 (I think Option 3 is probably going too far but listed it for completeness), we could potentially choose invalid_scope. That would overload it compared to not only its straight OAuth usage https://tools.ietf.org/html/rfc6749#section-3.3 but also our usage in Grant Sec 3.3.6 https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html#authorization-failure :

"At least one of the scopes included in the request does not match an available scope for any of the resources associated with requested permissions for the permission ticket provided by the client. The authorization server responds with the HTTP 400 (Bad Request) status code."

But maybe that makes sense.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/wg-uma/issues/347#issuecomment-320564213, or mute the thread https://github.com/notifications/unsubscribe-auth/AA6kNucmNtTU3eXBQvohM1KCicGEMjBhks5sVo3CgaJpZM4Omp01 .

jwilleke commented 6 years ago

AFIK, in all other references to scop, authorization server can ALWAYS based on any logic NOT to provide a requested scope value for any reason.

RFC 6749 4.2.2 Access Token Response: scope OPTIONAL, if identical to the scope requested by the client; otherwise, REQUIRED.

RFC 6749 4.2.2.1. Error Response "invalid_scope - The requested scope is invalid, unknown, or malformed." nothing about the scope not being registered.

It is up to the client to compare the scopes requested and confirm against the response.

So while I agree the "policy" may deem this an invalid scope, it is not a protocol or syntax error, but rather an individual policy violation.

I also liked the wording used within openid-connect-core-1_0 15.1. Mandatory to Implement Features for All OpenID Providers for Authentication Context Class Reference OPs MUST support requests for specific Authentication Context Class Reference values via the acr_values parameter, as defined in Section 3.1.2. (Note that the minimum level of support required for this parameter is simply to have its use not result in an error.)

-- -jim Jim Willeke

On Mon, Aug 7, 2017 at 3:25 AM, James Phillpotts notifications@github.com wrote:

For me, Option 2 is the only one that makes sense because I don't believe that we can always assume that a scope that is not pre-registered is either never (option 1) or always (option 3) an error.

On 7 August 2017 at 06:08, Eve Maler notifications@github.com wrote:

Thanks to Jim for the OAuth context.

We thought we were explicitly ruling out an error with the wording we chose, but I guess it's too ambiguous. We should not say merely "It is not an error" but, I think, rather one of the following:

  • Option 1: If the client requests a scope for which it has not pre-registered, it is not an error (... rest of rationale ...). The authorization server MUST NOT return an error for this reason.
  • Option 2: It might not be an error if the client requests a scope for which it has not pre-registered because (... rest of rationale ...). Alternatively, the authorization server MAY return (some error to be defined/chosen).
  • Option 3: If the client requests a scope for which it has not pre-registered, the authorization server MUST return (some error to be defined/chosen).

If we like Option 2 or Option 3 (I think Option 3 is probably going too far but listed it for completeness), we could potentially choose invalid_scope. That would overload it compared to not only its straight OAuth usage https://tools.ietf.org/html/rfc6749#section-3.3 but also our usage in Grant Sec 3.3.6 https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html# authorization-failure :

"At least one of the scopes included in the request does not match an available scope for any of the resources associated with requested permissions for the permission ticket provided by the client. The authorization server responds with the HTTP 400 (Bad Request) status code."

But maybe that makes sense.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/wg-uma/issues/347#issuecomment- 320564213, or mute the thread https://github.com/notifications/unsubscribe-auth/ AA6kNucmNtTU3eXBQvohM1KCicGEMjBhks5sVo3CgaJpZM4Omp01 .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/wg-uma/issues/347#issuecomment-320589231, or mute the thread https://github.com/notifications/unsubscribe-auth/ADcvsFzLlkhld3NJYJ2BWcjMNJ2Y2Injks5sVrv2gaJpZM4Omp01 .

ciseng commented 6 years ago

Regarding: "It is up to the client to compare the scopes requested and confirm against the response.”

In UMA, AS is not returning the scopes granted to the client - we discussed this in the group and decided that it will be confusing. Because, client does not know which resources/scopes were requested by the RS in the permission ticket.

mrpotes commented 6 years ago

Does 6749 define "invalid" (in the sense of "invalid, unknown or malformed") in such a way as to exclude invalidity due to the client that is requesting?

On 7 Aug 2017 10:11 am, "ciseng" notifications@github.com wrote:

Regarding: "It is up to the client to compare the scopes requested and confirm against the response.”

In UMA, AS is not returning the scopes granted to the client - we discussed this in the group and decided that it will be confusing. Because, client does not know which resources/scopes were requested by the RS in the permission ticket.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KantaraInitiative/wg-uma/issues/347#issuecomment-320611892, or mute the thread https://github.com/notifications/unsubscribe-auth/AA6kNgonRV17PgJE_r1yQRER-Wmdddjoks5sVtSygaJpZM4Omp01 .

xmlgrrl commented 6 years ago

Per UMA telecon 2017-08-23 (see complete meeting notes):