*Attending:* Eve, Justin, Domenico, George, Kathleen towards the end, possibly Dean on the screen *#284* <https://github.com/KantaraInitiative/wg-uma/issues/284>* if George has any further input; otherwise we can make this a last-call thing* Refresh tokens exist at all to enable access tokens to be short-lived. Separately from this, we’ve discussed how an UMA-enabled AS could leverage a short TTL strategy for RPTs. What does it mean for an AS to downscope an RPT based on a client requesting scopes at the token endpoint? Our current “MAY implement upgrading” text is clear and binary, and recommends documentation. We don’t currently say anything about downgrading. If a refresh token is returned, how would it be interpreted? It’s an OAuth refresh token, so — as Justin says — he’d interpret it to mean he could only get “the same” RPT or potentially one less powerful. But normally, OAuth allows a client, during a refresh flow, to include scopes for the purpose of downscoping. Justin suggests allowing scope values there but saying that the effect is undefined; this would be better than disallowing values. *AI:* Justin: Pull request to write up a new Section 3.10 describing refresh token flow profiling for purposes of UMA grant interaction, with a cross-ref from Section 3.6.6. With this, we can close #284. *#282* <https://github.com/KantaraInitiative/wg-uma/issues/282>* to see (briefly) if there's sufficient support for the suggestion, as we've been discussing it for a while* The key “business ecosystem” question is: Which way would we want to bet on whether an API publisher would be willing to request different permissions dynamically? Eve and Justin are pretty certain they wouldn’t. Justin is concerned about greater and greater complexity of the proposal, and hence premature optimization. The RS would need to keep tracking more information in order to optimize others’ experience. Are we right in thinking that, since we’re talking about enriching the information sent to the RS through a JSON format, this could be an experimentation that grows into a V2.x addition? We believe so. So there’s room to play with this later if we discover pain in some deployments. Let’s close without action for now, but anyone could take it up on their own initiative at any time if they see the need. Let’s create a label for all the potential extension work. *#254* <https://github.com/KantaraInitiative/wg-uma/issues/254>* (hashed claim discovery)* This could have implications for the whole need for protected discovery and so on. But on the other hand, is it an enabler for rainbow table discovery? So it needs some proper thinking and work. So this gets the close-without-action and extension labeling. *#267* <https://github.com/KantaraInitiative/wg-uma/issues/267>* (extensibility profiles)* Justin recommends excising Section 5 entirely. OAuth says it’s only about HTTP stuff, and ACE is still doing its thing, after all. What about adding just a sentence or two in the HTTP Usage section explaining why it’s important to still produce the on-the-wire artifacts (mainly tokens and their contents/introspection objects): it’s to support the legal toolkits. The rationale for this rationale :-) is that it connects the technical and legal worlds from the spec side. Justin disagrees. She will talk to Tim R to see if this is actually helpful, and if not, won’t put it in. Plan is to excise Section 5 in any case. *#263* <https://github.com/KantaraInitiative/wg-uma/issues/263>* and **#119* <https://github.com/KantaraInitiative/wg-uma/issues/119>* (claim token profiling)* Typo: In Sec 6, s/for for/for/ Justin agrees the whole “hybrid” thing makes no sense. But since the client is the primary audience of the ID token, we’re back to: - Narrow ecosystem: AS=IdP, in which case, it can be entirely “out of band” of UMA because the client already has the user (RqP) context. Eve notes that even in narrow ecosystems, which G2C seems to have a bunch of, interop can be valuable because of independent implementation. And then potentially in future phases, the vertical sectors might want to start combining. The question is, since we no longer have an AAT for “stateful” versions of same, should we pick a better string for the OIDC “stateless” version, namely, http://openid.net/specs/openid-connect-core-1_0.html#IDToken as Mike suggests? - A medium ecosystem where the audience field pretty much only works if the AS has pre-established trust with the RqP’s IdP — we don’t know of these in the wild yet, but Eve knows of some future-phase projects that may require these. Justin asks the question: What behaviors would change on the client’s part if the AS were to declare support for an OIDC mechanism vs., say, a SAML or PKI?? or whatever mechanism. - Wide ecosystem — Eve and Justin both expect these to use the interactive flow, which would bootstrap a PCT We could: 1. Just switch the string in the example, and not define it as a claim token profile or an UMA profile. 2. Define a claim token profile. 3. Switch the notion of claim token profiles to UMA profiles. Eve will try #1 for now, and issue #119 about IANA registries is pointless. :-) We can soften the language around “claim token profiles” and say it can be another kind of UMA profile if you feel the need. *#260* <https://github.com/KantaraInitiative/wg-uma/issues/260>* if anyone wants to argue for pulling cascading authorization servers forward into V2.0 at this time* At this point, not having had others besides Mohammad weigh in, we’ll close without action and put the new extension label on the issue. *#270* <https://github.com/KantaraInitiative/wg-uma/issues/270>* (making "uri" an array, and possibly a wildcard)* Justin feels this adds complexity without commensurate benefit. He doesn’t understand what the additions buy you. Mike may need to flesh out his proposal, and maybe this is in extension-land. Unfortunately, if we did make this an extension, we’d be looking at an unattractive object-vs-array choice because registering one uri now vs. an array later through a different property ?? is awkward. *#288* <https://github.com/KantaraInitiative/wg-uma/issues/288>* about using OpenAPI for RReg, and I just remembered to label it properly* Justin feels this adds complexity without commensurate benefit. Why not choose SCIM instead? :-) “REST works because it’s a pattern, not because it’s an API.” Sometimes, what you’re protecting is in fact a “true API”, and in that case, perhaps you might want to extend the resource registration document with OpenAPI stuff, but otherwise not. In which case, maybe this is in extension-land too. But if you’re registering photos or whatever, it may or may not be appropriate or a particularly good match. *Shoebox endpoint work…* *AI:* Eve: Put the extension label on this stuff too. *Looking at the kinds of issues we have open at this point, one of the things to consider -- given that we'll be asking people to **join the group in order to give feedback** -- is whether we feel comfortable considering cutting loose a WG draft with "must-fix" issues closed, but keep working on tiny other ones, or what.* Eve shared her “UMA2 Basics” deck with Domenico. He and she will work on adding graphics and other content to it to help convey the changes to people, e.g. authorization assessment and other stuff. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Mar 6, 2017 at 7:55 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Almost forgot, for completeness's sake in this thread: Mike S put in issue #288 <https://github.com/KantaraInitiative/wg-uma/issues/288> about using OpenAPI for RReg, and I just remembered to label it properly.
*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Sun, Mar 5, 2017 at 11:50 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Folks, I apologize for getting this ad hoc into the calendar only now; if you recall, we agreed on Thursday that we'd meet on Monday (tomorrow!) 8:30-10am Pacific. I *may* get dragged away sooner than that because of my delay... (Long story.)
For tomorrow, let's switch back to the open Core issues, and then go back to the open RReg issues, in this order:
#284 <https://github.com/KantaraInitiative/wg-uma/issues/284> if George has any further input; otherwise we can make this a last-call thing #282 <https://github.com/KantaraInitiative/wg-uma/issues/282> to see (briefly) if there's sufficient support for the suggestion, as we've been discussing it for a while #254 <https://github.com/KantaraInitiative/wg-uma/issues/254> (hashed claim discovery) #267 <https://github.com/KantaraInitiative/wg-uma/issues/267> (extensibility profiles) #263 <https://github.com/KantaraInitiative/wg-uma/issues/263> and #119 <https://github.com/KantaraInitiative/wg-uma/issues/119> (claim token profiling) #260 <https://github.com/KantaraInitiative/wg-uma/issues/260> if anyone wants to argue for pulling cascading authorization servers forward into V2.0 at this time #270 <https://github.com/KantaraInitiative/wg-uma/issues/270> (making "uri" an array, and possibly a wildcard) ...
Looking at the kinds of issues we have open at this point, one of the things to consider -- given that we'll be asking people to *join the group in order to give feedback* -- is whether we feel comfortable considering cutting loose a WG draft with "must-fix" issues closed, but keep working on tiny other ones, or what.
*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl