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