UMA telecon 2016-09-29

...

Minutes

Roll call

Quorum was not ? reached.

Approve minutes

Approve minutes of UMA telecon 2016-09-22 : ?Deferred.

Work on UMA.next issues

We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends.

...

James had proposed set math as follows:

(ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes

The questions for the spec are:

• What does the RS have to do at API publication time, if anything?
  • There will be scopes published, whether in informal fashion or, say, Swagger (machine-readable)
  • Nothing much more to say about this, probably (we have some editorial notes on it)
• What does the client have to do at scope registration time, if anything?
  
  • It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it)
• What does the RS have to do at permission ticket registration time?
  • In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other
  • This remains to be fully discussed, though we started it at CIS
  • Can the client request scopes from the RS (in addition to just attempting access)? (added after the call: see George's comments from 2016-08-04 about efficiency of client communications for smart clients)
• What does the client have to do at RPT request time?
  • How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)?
  • In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possibleWe mostly have to figure out the syntax here – we haven't spec'd it yet
• What does the AS have to do at RPT issuance time?
  • In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it
  • There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer)

 Spec instructions:

• See above!

...