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

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 | Twitter | Facebook

 

DD: +44 (0)1865 332256    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 list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma