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 ever want to request more, different, or fewer permissions than correspond to the client's access attempt?
  • Why would the RS ever be forced to 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 the RequestedScopes "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.
Mobile:+1-703-462-3494  Office:+1-703-265-2544