Page Comparison

...

• Can we dispose of current issues and pass a motion to move to public comment and IPR review period today? Potentially recommend actions on issues, but likely not pass a motion.  We could do an e-ballot, which takes (we think) 7 calendar days. Eve will take it under advisement. Note that Justin (a non-voting participant) can't make next Thursday's call.
• If so, what to do in the interim WG-wise? n/a for now.

UMA V2.0 work

...

• Note: How the resource server validates the RPT is outside the scope of this specification, but it may be useful to consult [UMAFedAuthz].#303: JSON usage and OIDC for client authentnication: These security considerations have been removed from the drafts, and it doesn't seem they'd be missed. Unless anyone yells, we'll close this issue for May 12.
  • Let's close the issue.
• #304: Do we need the invalid_request issue (that is, error)? It would only be for FedAuthz (the protection API). I've taken it out for now. Request messages have their own custom errors for specific things that could go wrong. Basically, yell if you see a need to add it (or any other more-specific errors) back, or we'll close this with no action by May 12.
  • None of us could think of a reason to need it, and it's already gone. Close the issue.
• #306: Best to keep downscoping undefined when refreshing? I've now included a rationale in the refreshing language in Grant. Given the current state of Grant and FedAuthz, let's plan to close this without action by May 12 unless someone has a problem.
  • 6749 is actually more subtle about constraining what the client can ask for in terms of downscoping, and maybe we can make use of this. If the scope parameter is left off, we should state that "If the client does not include the scope parameter, then the refreshed RPT has the same permissions as the original RPT." But is this right? What if some expired since then? Should there be a reevaluation? This is the question of the simple authorization decision model of OAuth and the more complex policy decision model of UMA; when should policy decision-making happen? E.g., before issuing refresh tokens (that is, when issuing the original access token)? When between presented with a refresh token and being asked for a freshened-up access token? Remember that refresh tokens themselves should have appropriate TTL periods, and maybe the refresh token should die if the RPT would be useless later.
  • Try this: In Grant Sec 3.6: "If the client includes the scope parameter in its request, the authorization server MAY limit the scopes in the resulting permissions to those requested by the client." In other words, if the client mentioned scope A, and the original RPT had scope A on resource 1, then the new RPT will leave out resources 2, 3, and 4 that didn't have scope A on it. Yes, the client could hurt itself, but whaddya gonna do? The whole point of refresh is that you can ask for less, but without the user (RO in the case of other grants and RqP in the case of UMA) involved, you can't ask for more.
  • In Grant Sec 3.3.5, after "This is because RPTs are associated with scopes that are associated with specific resources." say "Note: The outcome of authorization assessment may result in expiration periods for RPTs, permissions, and refresh tokens that can affect the client's later requests for refreshing the RPT."
  • In Grant Sec 3.6, add "The authorization server MUST NOT treat the client's request to refresh an RPT as if it were a request for a new RPT requiring an authorization assessment calculation."
  • Editorial instructions:
    • Grant Sec 3.1: Instead of "Note: How the resource server arranges for resources to be protected in the context of a resource owner is outside the scope of this specification, but it may be useful to consult [UMAFedAuthz]." say "For an example of how the resource server can put resources under the protection of an authorization server, see UMAFedAuthz."
    • Grant Sec 3.2.1: Instead of "Note: How the resource server arranges to obtain the permission ticket from the authorization server is outside the scope of this specification, but it may be useful to consult [UMAFedAuthz]." say "For an example of how the resource server can obtain the permission ticket, see UMAFedAuthz."
    • Grant Sec 3.3.4: Instead of "Note: [UMAFedAuthz] describes how the resource server MAY obtain the permission ticket from the authorization server." say "For an example of how the resource server can obtain the permission ticket, see UMAFedAuthz."
    • Grant Sec 3.5: Remove both "Note: How the resource server validates the RPT is outside the scope of this specification, but it may be useful to consult..." and "Note: [UMAFedAuthz] describes how the resource server MAY introspect the token at the authorization server preparatory to responding to the client's request." and replace with...
• #307: Lower-priority, but nice to think about since there are already a bunch of profiles and extensions: Should we create a "pseudo-IANA-registry" for profiles and extensions?
  • What few items could we get away with? And if there's a huge profile or extension vs. individual items, do we need a registry approach? Actually, the URI as the identifier and the plea to put it into our discovery document are the most important part. We can probably trash the rest.
• #308: Really kind of low-priority: Should we flatten the innards of need_info to remove the error_details layer? If no one pays attention to this before May 12, let's close without action.
  • Eve (lightly), Justin, and James are in favor. Sarah's and Justin's original proposal kind of went in this direction already. Let's do it.
• #310: NEW and important, highlighted by Mike: Our requirement to have the client pre-register for scopes is likely at least somewhat problematic. See the issue for why. (Domenico, this would potentially affect your Venn...)
  • Justin and James had weighed in to keep this as is. This has security implications. Mike is okay with keeping it as is. Justin notes that clients are not OAuth-generic; only libraries. Cigdem agrees. Let's close without action.
• #311: NEW and would be nice to look at: We go on and on about how the PAT is susceptible to implicit grant threats, but this seems like just a generic OAuth threat (especially with our refactoring now), and everyone is familiar with it. Remove?
  • Let's remove. We do have to add something saying "The PAT is an OAuth token and, as such, is susceptible to OAuth threats."
  • We should also submit the writeup we're taking out 

AI: Eve: Implement editor's instructions, send out revs 04, and update all the relevant issues.

Attendees

As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem)

1. Eve
2. Mike
3. tbsCigdem

Non-voting participants:

• tbsJustin
• James

Regrets:

• tbs