Some notes to adjust how the flow would literally go: - The client first *attempts access at the RS*, and can only "do one thing" there (say, execute access), because attempting access is what it is. The RS takes this access attempt as a hint, and bases its permission request on that. In truth, it's hard to request less than one scope, but it could request a different scope, say, read instead of execute. - With such a ticket in hand, the client approaches the *AS*, and having attempted execute access, it asks for read and write access too. - The RO might have set a policy that allows the requesting party to have all three scopes on that resource. So, as Justin says, it's possible the RPT would ultimately contain all three lovely scopes. But the RS has one last chance to apply edge protection once the client brings it the token. (This is where our upcoming discussion on "shoebox" will start to come in...) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Jan 5, 2017 at 3:04 PM, Justin Richer <jricher@mit.edu> wrote:

I don't believe this situation should result in an "invalid_scope" error. Instead, since the client and the RO's policy allow for A, B, and C, the client should get A, B, and C in the resulting RPT even if the RS registered something less.

But this is exactly the kind of question that I meant when I first said that we should make the decision of which scopes apply where to be deterministic, and why we need this set math discussion to conclude with a single answer.

-- Justin On 1/5/2017 1:23 PM, Cigdem Sengul wrote:

Thanks, it was an interesting discussion.

Regarding “ The resource server has discretion over the extent of access covered by the request (see Sec 3.3.3); … even a lesser extent. “

Is the following scenario possible?

- Client asked resource 1, scope A, B, C.

- RS registered a lesser extent, due to edge protection, i.e., resource 1, scope A and B.

- RO has a policy that allows A, B and C for this resource for this client

With the ticket, the client approaches to RS, and asks for scopes A, B, C in its request.

This would generate an invalid_scope error as the requested scopes do not match the ones in in the ticket.

I believe this is what was discussed in the call: giving the client a clue about what scopes have been registered in the permission ticket.

In this case, client got an error. If it did not include any scopes in its request, it would still not get scope C. RO cannot do anything about it.

Does this mean

- RS and RO need to resolve this offline?

- RO is trying to give a scope on a resource that is not under its authority?

Or

The RO would never be able to give a permission that allow C on resource 1, in the first place?

Thanks,

*Cigdem Sengul, PhD*

Senior Researcher

*Website* <http://www.nominet.uk/>* | **Twitter* <https://twitter.com/Nominet>* | **Facebook* <https://www.facebook.com/nominet/>

DD: +44 (0)1865 332256 <+44%201865%20332256> E: cigdem.sengul@nominet.uk

Minerva House, Edmund Halley Road, Oxford Science Park, Oxford, OX4 4DQ, United Kingdom

Nominet UK. Registered in England and Wales No. 3203859

This message is intended exclusively for the individual(s) to whom it is addressed and may contain information that is privileged, or confidential. If you are not the addressee, you must not read, use or disclose the contents of this e-mail. If you receive this e-mail in error, please advise us immediately and delete the e-mail. Nominet UK has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. However, Nominet cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment.

--Cigdem

_______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma