Here are some topics and questions after thinking about our recent set-math conversations and collaborating with Eve.
I think there a few different areas we need to resolve:
1. PreviousRPT
Is this a super token? All rsid:scope tuples are continually added (and expired)
Is this a single token per RqP at the client? Does it also need to be bound to the RS?
Are super-token's a good idea? Do we want to promote them?
Motivation?
reduce coding complexity for the client?
reduce user experience complexity for the user?
i.e. the user doesn't have to keep providing the same claims over and over
Can we get the same behavior (improved user experience) for the user by using the PCT?
If we do want to keep the ability to add a previous RPT to a request, what is the effect on authorization assessment?
Does this effect change in the presence of a PCT on the request?
2. Partial results
Why would the client pre-register for scopes? How does it choose?
How does the client choose what to attempt access to (what API call)? Does it think in terms of scopes at this point?
Note: It attempts access both with and without an RPT. The RPT may or may not be sufficient. It currently doesn't know.
Why would the RS everwantto request more, different, or fewer permissions than correspond to the client's access attempt?
Why would the RS ever beforcedto request more, different, or fewer permissions than correspond to the client's access attempt?
Why would the client request scopes at RPT request time? How does it choose?
Should the AS consider any of theRequestedScopes "privileged" such that if they make it to CandidateGrantedScopes, it has to grant them (these are the partial results that succeeded)?
Should the AS inform the client about RPT issuance results, say, scopes granted, scopes denied, fact of partial results, etc.?
What to do when the RS (and/or client) requests more than is absolutely necessary for the initial access request?
Is the RS responsible for determining what is "absolutely necessary"? If not, who?
What is the expected behavior if the RS can NOT determine what is "absolutely necessary"?
Should the client be informed that only some of the requested permissions in the permissionTicket were met?
Should the client be informed that scopes it specifically requested on the /token call were denied?
3. Looping
Whose responsibility is it to determine the user is in a "permissions loop" and stop the loop and help the user?
client?
RS?
How do we envision this worknig? Do we need to add anything to the spec to help with loop detection?
4. API design / scope models
how prescriptive do we want to be about API design / scope models for UMA?
Can we document what API design / scope models we see being used with UMA today?
What guidance can we give on these topics?
--
Distinguished Engineer Identity Services Engineering, AOL Inc.