- WG-UMA - mailman.kantarainitiative.org

Revs 13 and 05 are up
by Eve Maler 25 Jan '17

25 Jan '17

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-13.html https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-05.html Key things to note: The biggest thing is that the Authorization Assessment section <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-13.html#authorizatio…> is back, and it's reworked with something like George's example. The discussion of "default-deny" is much much softened. Throughout there are some subtle but -- I think -- helpful changes in response to lots of comments from Cigdem. More of that to come. Based on a discussion with Cigdem (and also the discussions with the HEART WG), I think we need to add a discussion of the importance of the RS treating its permission request practices as a part of its API behavior. Something to discuss... I will send a specific agenda tomorrow -- gettin' late now. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Set math, authorization assessment, and implementation questions (from George)
by Eve Maler 25 Jan '17

25 Jan '17

The following is the "lost email" from George on questions about how the AS might manage registered scopes/resource IDs and the policy conditions that will have to govern the assessment process. ==== I wanted to start a different thread that relates to the "set math" discussion but is more focused on the relationship between resource registered scopes and resource owner policy (ROPolicy). Please correct any incorrect thinking that follows:) In order for a RO to define policy for a given resource, the RS must first register that resource set with the AS. When the RS registers the resource set with the AS, the RS defines what scopes are allowed for that specific resource set. The RO can then go to the AS and find the resource set and define policies that link to the scopes associated with the resource set. Following on my example from the "set math" thread, lets say my photo service registers two resources: rsid_1: photos/gff/landscape scopes: view, link, download rsid_2: photos/gff/family scopes: view, link, download, print When I (as the RO) go to the AS, I'm assuming that I get to define the policy for each of the scopes associated with each of the registered resource sets. Now in practice, I suspect that as the RO, I want an AS that allows me to define sets of claims and then map those to the scopes associated with the different resource sets. Lets assume I've defined the following policy claim sets at the AS. family -- list of individuals that are part of my family photo_viewer -- promises to not download/sell/market any photo I then map the above policies to the resource sets and scopes as follows... rsid_1: view, link -- photo_viewer download -- family rsid_2: view, link, download, print -- family Now, when the client tries to access photos/gff/landscape the RS registers a permissions ticket with scopes for "view" and "link" but not download. The client then presents the permissions ticket to the AS and the AS determines which claims the RqP needs to meet in order to be authorized for those scopes. In this case, both scopes require the same claims (photo_viewer). Now, if the client requested the "download" scope in addition to the scopes in the permissions ticket, then the RqP must meet the family claims in order to get access to that scope. I'm assuming we are leaving it up to the AS to determine whether to fail the RPT request if the RqP can NOT meet the family claim, or return "view" and "link" but NOT "download". The latter feels more like OAuth2 though I'm guessing in more complicated cases this could get dicey:) So RPT request processing at the AS should, I think, be determined by the intersection of the set of scopes defined for the resources set and the set of scopes requested. Simplifying slightly from Justin's set math... scopesToProcess = intersection(Requested, RSReg) The AS then needs to iterate through the "scopes to process" to determine the claims the RqP needs to meet in order to grant an RPT with that set of scopes. for each scope in scopesToProcess { claimsRequired += claims(rsid, scope) } normalize/merge claimsRequired Once the required set of claims is defined, the RqP/client can go through claims negotiation. Depending on which claims are met, the associated authorized scopes can be determined. claims met == promise to not download/sell/market scopes authorized based on claims met view, link If the set of authorized scopes is NOT a super set of the scopes requested in the permissions ticket, the RPT request fails. Otherwise, return the scopes authorized. In this context, I don't think the PrevRPT provides much value, however, a token defining previously satisfied claims provides a lot of value. Does that resonate with how others envision the logic and flow working? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

270: Resource Registration Document: 'uri' should be an array / examples
by Eve Maler 24 Jan '17

24 Jan '17

In this message, I want to share the results of the ad hoc discussion we had after Thursday's formal call ended. *No set of options or proposal in this one*, because I think we need to discuss it more. Please read and weigh in before the next meeting! Here's the relevant part of the notes <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19> : ==== *270 <https://github.com/KantaraInitiative/wg-uma/issues/270>: Resource Registration Document: 'uri' should be an array / examples:* Gluu had actually assumed this was already an array, and implemented it that way! And wildcards would be really handy. Especially with the ability to request permissions (get permission tickets) "in bulk" now, registering resources seems to be an obvious parallel task that should be done in bulk. Note that there are two theories about *when* to register resources: eager (when they are created at the RS/host), and lazy (when the resource owner wants to share them). The latter puts resource registration very close to the time of permission requesting. So they would seem to want to be aligned. (Also note that our current design of requesting multiple permissions (resource IDs) has us using an array, but requesting a single permission (resource ID) uses an object! Other instances of ability to "do multiple things with one thing as an edge case" in the spec, as designed natively in V1.0, are all done as arrays. ==== There are a couple of things that could potentially be going on here; we could take action on either of them, or both. First, Mike has pointed out that the optional "uri" field a) has been given short shrift (it's not in any examples and should be, because developers often only implement what's in examples) and b) would be valuable if it were made more powerful, to allow the RS to associate multiple URIs with a single resource ID through registration. Conveying this information allows the AS to take on the web access management (WAM) job of managing a set of protected URIs, and even a wildcarded set (as shown at the linked issue with an asterisk), as mapped to a single logical resource ID at the RS. The other cool thing the AS can do with the "uri" info is enable discovery of resource locations. Options around this might include something like "Consider changing/extending the 'uri' property structure in the resource description document." Second, what I originally thought when Mike brought this up to me was that the RS might want to literally *operate on multiple resources at one time* when doing CRUD operations at the RReg API. I actually keep confusing the two ideas (sorry about that), , which is why the meeting notes above read as they do. So, for example, if the client approaches the RS to attempt access to some resource, and the RS (using "lazy" resource registration and a "generous" permission request regime) needs to register the three resources that it wants to then request on the client's behalf, it has to do three *inefficient* Create requests in a row to the resource registration endpoint before doing one *efficient* call to the permission endpoint. Options around this might include something like "Consider changing the RReg API calls to allow creating/reading/updating/deleting multiple resources at once." (Listing already happens on a whole set.) ==== Thoughts, everyone? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 4

271, 272: Add description fields to resource description doc and scope description doc
by Eve Maler 23 Jan '17

23 Jan '17

In this message, I want to share the results of the ad hoc discussion we had after Thursday's formal call ended, and present options for going forward, along with a proposal. Please read and weigh in (even with a +1, if you agree...) by *Tuesday* if possible!) Here's the relevant part of the notes <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19> : ==== *271 <https://github.com/KantaraInitiative/wg-uma/issues/271>, 272 <https://github.com/KantaraInitiative/wg-uma/issues/272>: Add description fields to resource description doc and scope description doc:* ... Resource description docs don't need I18N/L10N, but scope description documents might, for both a friendly name field and a description field. If we added a description field to scopes, then, do we want to make a breaking change and make this an array? Or leave the name as a default name that never changes and add an intl_name field or something like that? Or not care at all about I18N/L10N, but then possibly break things in future? ==== Here are the options I can think of. (Let me know if I missed any.) 1. Do nothing. Others can always add their own extension for this. 2. Add a "description" property for the resource description document only. 3. Add a "description" property for the scope description document only. 4. Add a "description" property for both the resource description document and the scope description document. 5. (Not mutually exclusive with options 2, 3, or 4:) Add an internationalization/localization way for description values, likely modeled on the OIDC "claim request hash trick". ==== Here is my proposal: *Option 1*. Rationale: - A description field is pretty much a natural adjunct to a short name string. However, the interop cost is low if others add their own description fields. They might need multiple descriptions for different purposes. A display name seems like minimal bootstrapping, whereas descriptions may be gilding the lily. - I don't feel that strongly about it, however, and could be convinced by *Option 2 or 4* (but I'm not crazy about Option 5, as detailed in the issue 269 email). *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

269: Resource Reg Section 2.1: "URI MUST resolve to a scope description document"
by Eve Maler 23 Jan '17

23 Jan '17

In this message, I want to share the results of the ad hoc discussion we had after Thursday's formal call ended, and present options for going forward, along with a proposal. Please read and weigh in (even with a +1, if you agree...) by *Tuesday* if possible!) Here's the relevant part of the notes <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19> : ==== *269 <https://github.com/KantaraInitiative/wg-uma/issues/269>: Resource Reg Section 2.1: "URI MUST resolve to a scope description document":* Resource description documents are "private" and specific, but scope description documents are public and meant to be possible to standardize (e.g. pointing to third-party scope description documents), and thus, things like internationalization and localization of strings could be tricky. So a MUST is a big problem. At best, we can say that it's all down to developer documentation, not anything run-time. And as Mike pointed out, a URN isn't run-time resolvable in practical terms. Since we rely on dynamic registration of resources and scopes, how ideally should this work? Eve wonders if we should add a new option: the string-based scope in a resource description is fine, a URI-based one that doesn't resolve is fine, but the RS could also resolve the scope description and stuff it into the resource description by value during registration. George notes that OIDC's "claim request hash <http://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsLangua…>" mechanism for handling localization could work. Mike asks if we're overdesigning. [image: (smile)] We're generally not crazy about playing I18N and L10N games with scope strings, either. At the very least, we have to qualify that if the scope is a URN they don't have to resolve. And at the very least, the AS has to be prepared for failure to access any required scope description information. ==== Here are the options I can think of. (Let me know if I missed any.) 1. Do nothing. 2. Change minimally to say the URI MUST resolve scope references to a scope description document only if they're URLs and add failure logic. 3. Change more to say that the AS SHOULD attempt to resolve the reference URL, but soften the language generally and acknowledge that it's more in the realm of developer documentation. 4. Change even more to say that scope description metadata is possible to standardize, publicize, and reference through a URI, but there is no expectation of run-time resolution by the AS; rather any customization of policy condition setting interfaces with respect to scopes is, um, out of scope. 5. (Not mutually exclusive with any of the above:) Add an internationalization/localization way for handling user-exposed strings in the scope description document, likely modeled on the OIDC "claim request hash trick". ==== Here is my proposal: *Option 4 alone, not with the option 5 rider*. Rationale: - Most scopes are still firmly in simple-string territory. - Especially given that clients have the option of pre-registering for scopes, and that scopes are generally the "public-safe" part of any API, there's a lot about scope semantics that's beneficial if it's documented ahead of time. - The less dependency on run-time calls to potential third parties for UX elements, the better. - I can see the argument for the "claim request hash trick" if we're concerned about I18N/L10N, but given my first rationale and the fact that even OIDC puts this trick into the MAY and SHOULD category, I think it's a nice-to-have that could easily just become an optional practice among those who need it that gets absorbed much later. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

273: Remove reference to "user" in List Resource Descriptions
by Eve Maler 23 Jan '17

23 Jan '17

This message discusses an issue not brought up yet in our meetings; I encourage you to follow the link and read the thread in GitHub before discussing here (or there...). *273 <https://github.com/KantaraInitiative/wg-uma/issues/273>: Remove reference to "user" in List Resource Descriptions* Perhaps despite headline appearances, this is a rather philosophical issue In the thread. At the end of the thread, I make a proposal: "We could say more here about how the AS-RS trust model and the ability to recognize resource owner context within that trust model determines the behavior of the operations. (It's not just List that's affected, it's actually all of them.) If OAuth is used for protection, then the AS-RS trust is formed in an in-band manner and the necessary context is passed in the authorization header. If any other method is used for protection, then trust is formed in some manner that is not in-band, and the necessary context has to be established in some other way. UMA happens to use the former." The PAT really is the special contextual sauce that makes a whole bunch of things in UMA work... Thoughts on adding this? Separately, in looking at what other UMA-specific elements might be holding RReg back from generic application to OAuth (and OIDC, for OP/AP linkages), the only thing I'm coming up with is the mention of "policy setting" (active) as possible uses of info in the description documents. But even then, "resource protection monitoring" (passive) is another listed usage. And it would be cool if other grants of OAuth started to use RReg to centralize management of where your access token is, so that you can go and revoke it -- a kind of policy setting, if crude. Am I missing anything else? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

The dynamic UMA 2.0 swimlane is updated
by Eve Maler 22 Jan '17

22 Jan '17

Thanks to Justin for doing some "interactive claims gathering" work in our swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd>! That was what I was setting out to do this morning, so it was a nice surprise. I did some other stuff to make sure it was all up to date, accurate, and coherent for the new "authorization process" and "set math" bits. Please yell if you've got comments or questions. This will become more and more useful with each passing day. The wiki home page now also has links to our latest drafts, and I've added the swimlane too. I'm also gearing up to add to our Release Notes <http://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes> document at some point soon after (or just when?) the public review period starts. I also prepared a short slide deck describing what's up with UMA 2.0 (so far, anyway) -- more on that soon. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-01-19
by Eve Maler 20 Jan '17

20 Jan '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-01-12 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-12>: APPROVED. Logistics - Meeting countdown: Jan 19 (today – week 0), Jan 26 (next week – week 1), Feb 2 (the week after – week 2), Feb 9 (*WG Draft and Public Review vote* – week 4) - We should strive for issue burndown and substantially complete specs by Feb 2 if possible – I may be calling on specific people to help close nitsy but not-very-substantial issues - No meeting Feb 16 because of RSAC We should schedule an RSAC no-host drinks BOF. UMA V2.0 work *266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math:* The "default-deny" paragraph is still relevant because it's all about policy conditions, which are OOS for UMA, and you could have default-permit policies, which are pernicious. Maybe this statement should use a lowercase "must" because it can't be made testable, and say "must use a best effort" or something. For certain use cases, like "crunchy-shell security", or even "policies inside a micro-domain of permissiveness", how does an AS even manage access control? In any case, this paragraph should travel with the set math logic paragraphs (which we think should go back into an Authorization Assessment sub-section in Sec 3.6, which disappeared in rev 12). A client can request (and register for) scopes around a public/standard API based on anticipated RS behavior around requesting permissions. But then if it knows the RS is going to put something in the PermissionTicket, it need not do anything. And a clueless client can also not register for or request anything. So an RS implementing a public/standard API (like FHIR) could document its practices around resource/scope requesting, and the client is all taken care of. But it's more private/proprietary APIs where the client has to take more responsibility. George's email <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/6Wx5NmXuL…> is a great example of the two paragraphs that were removed from rev 11's Authorization Assessment section <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-11.html#authorizatio…>. In fact, the two paragraphs are about the same subject. If the AS determines that the non-null GrantedScopes value isn't useful for the client for whatever reason, then it shouldn't be forced to grant an RPT; it should be allowed to error, in the same spirit as our not forcing the RS to return success in its response to the client <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-12.html#give-access> on sufficiency of authorization. How to handle PreviousRPT in all this? The AS would have to find all the claims relevant to having met all the scopes in that RPT. The task in email now is to look at when the previous RPT a) did and b) didn't contain resource IDs that were in the current request for access. *Shoebox: 246 <https://github.com/KantaraInitiative/wg-uma/issues/246> etc:* Eve's and Adrian's discussion has been happening in email <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/dwJVOsI-K…>. George notes that it could be quite valuable for an AS to have audit logging functionality, as captured in several of the issues. Mike makes a plea for not making breaking changes. George also notes that the Security Events group at IETF <https://datatracker.ietf.org/wg/secevent/charter/> is working on something relevant as well (see the Security Event Token spec <https://datatracker.ietf.org/doc/draft-hunt-idevent-token/>). There's a fair amount of interest, though time is short. The work seems possible to parallelize; an extension that proposes an endpoint and formats as required (or multiple extensions specs proposing more than one?), and the right community of interest that requires to use UMA along with an AS that presents that endpoint, would allow for rapid experimentation. However, Adrian would like this not to be an extension. We have consensus to proceed on this work as a separate modular activity. *260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers:* Recall that the use case (from the FHIR world) is that the RS has "edge authorization" it needs to perform, which it has ensconced in enterprise policies in its own authorization server. This is a way to have the "Adrian clause" reified in RPTs, and the client/RqP meet multiple sets of policy conditions, all the way. This connects to the shoebox question if you can get the RS to report what they've done. In the swimlane, the "downstream AS" is Alice's and the "upstream AS" (and any further upstream ones) belongs to the RS. So, in a way, this has positives and negatives: the incentives change because on the one hand an RS gets a lot more formal and dynamic control of liability, but on the other, it can control much more strongly what Alice gets to share, possibly enabling "data blocking" (a phrase from the health world). This has been done as an extension already, so it could remain an extension for now. It has "set math" implications, because it introduces another set. Eve's observations about the flow: - AS needs to know about the other AS because it's a client of the permission request endpoint - Client needs credentials for the upstream AS(s) too - Client needs to keep an "AS stack" and to hold multiple RPTs for "that resource" (whatever that means to the client) - (George added:) There's new set math that each downstream AS has to calculate George wonders if you could do this without cascading. Could the RS just issue a request that's "out of band", redirecting to each AS as necessary, and then when each process completes, there's some kind of meta-RPT structure, like a JWT that aggregates RPTs? We're inclined to suggest this stays an extension for now. We'll check in with each other and the proposers next week. Editing instructions: - Put our conclusions into Core rev 13. - (From ad hoc:) Try some language to soften the requirement for the AS to resolve the scope description document URI (issue 269). - (From ad hoc:) Send emails about each of the RReg issues. *(The official meeting ended and we kept going ad hoc to discuss RReg issues.)* *269 <https://github.com/KantaraInitiative/wg-uma/issues/269>: Resource Reg Section 2.1: "URI MUST resolve to a scope description document":* Resource description documents are "private" and specific, but scope description documents are public and meant to be possible to standardize (e.g. pointing to third-party scope description documents), and thus, things like internationalization and localization of strings could be tricky. So a MUST is a big problem. At best, we can say that it's all down to developer documentation, not anything run-time. And as Mike pointed out, a URN isn't run-time resolvable in practical terms. Since we rely on dynamic registration of resources and scopes, how ideally should this work? Eve wonders if we should add a new option: the string-based scope in a resource description is fine, a URI-based one that doesn't resolve is fine, but the RS could also resolve the scope description and stuff it into the resource description by value during registration. George notes that OIDC's "claim request hash <http://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsLangua…>" mechanism for handling localization could work. Mike asks if we're overdesigning. [image: (smile)] We're generally not crazy about playing I18N and L10N games with scope strings, either. At the very least, we have to qualify that if the scope is a URN they don't have to resolve. And at the very least, the AS has to be prepared for failure to access any required scope description information. *271 <https://github.com/KantaraInitiative/wg-uma/issues/271>, 272 <https://github.com/KantaraInitiative/wg-uma/issues/272>: Add description fields to resource description doc and scope description doc:* We just discovered that, since the "name" properties are defined to be friendly names, we don't really have a separate machine-readable name. Do we need one of those separately? But these issues are about "description". Resource description docs don't need I18N/L10N, but scope description documents might, for both a friendly name field and a description field. If we added a description field to scopes, then, do we want to make a breaking change and make this an array? Or leave the name as a default name that never changes and add an intl_name field or something like that? Or not care at all about I18N/L10N, but then possibly break things in future? *270: Resource Registration Document: 'uri' should be an array / examples:* Gluu had actually assumed this was already an array, and implemented it that way! And wildcards would be really handy. Especially with the ability to request permissions (get permission tickets) "in bulk" now, registering resources seems to be an obvious parallel task that should be done in bulk. Note that there are two theories about *when* to register resources: eager (when they are created at the RS/host), and lazy (when the resource owner wants to share them). The latter puts resource registration very close to the time of permission requesting. So they would seem to want to be aligned. (Also note that our current design of requesting multiple permissions (resource IDs) has us using an array, but requesting a single permission (resource ID) uses an object! Other instances of ability to "do multiple things with one thing as an edge case" in the spec, as designed natively in V1.0, are all done as arrays. To be floated on the list, and only discussed if not resolved prior. Attendees As of 22 Dec 2016 (post-meeting), quorum is 5 of 9. (Domenico, Sal, Nagesh, Andi, Maciej, Eve, Mike, Cigdem, Sarah) 1. Domenico 2. Sal 3. Eve 4. Mike 5. Cigdem 6. Sarah Non-voting participants: - Adrian - George - François - Colin L. - Scott F. Regrets: - James - JohnW - Andi - Maciej *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA Legal: a bit of a hiatus / other activities
by Eve Maler 20 Jan '17

20 Jan '17

I've confirmed that we'll be seeing an interim deliverable not earlier than the end of February, so I'm going to remove our meetings from the calendar until then. Please stay tuned for news in that timeframe. By the way, I had occasion to point to our draft primer text (among providing other text/thoughts) to support when the Kantara marketing and PR folks asked for perspective on UMA's relevance to GDPR. If you would also like to provide your perspective, please ping me and I'll put y'all together. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-01-19 (90 minutes)
by Eve Maler 18 Jan '17

18 Jan '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-19 Date and Time - *Thursdays,* *special meeting times through Feb 9: 8:30-10am PT* - Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web calling interface <https://panel.turbobridge.com/webcall/> / code 1782540 - Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-01-12 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-12> - Logistics: - Meeting countdown: Jan 19 (today – week 0), Jan 26 (next week – week 1), Feb 2 (the week after – week 2), Feb 9 (*WG Draft and Public Review vote* – week 4) - We should strive for issue burndown and substantially complete specs by Feb 2 if possible – I may be calling on specific people to help close nitsy but not-very-substantial issues - No meeting Feb 16 because of RSAC - UMA V2.0 work - 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> / GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> (all issues to be kept here for the duration!) / dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Core is up to 12 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-12.html> (updated) and RReg is up to 04 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-04.html> (no change) - Set math and UMA grant vs. authorization interface updates; figure 3 removed - 266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math - Critique new wording (Core Sec 1.4.2, Sec 9.4, and impacts on Sec 3.6) and ensure it's sufficiently specified – e.g., the AS knows about resource IDs but the client doesn't, and the permission ticket can refer to multiple resource IDs, so is everything clear from that perspective? - Decide whether we need to be specific about AS implementation details (George's email <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/6Wx5NmXuL…> ) - Account for "previous RPT" logic - Shoebox: 246 <https://github.com/KantaraInitiative/wg-uma/issues/246>: Endpoint for collection of "receipts" and notifications of RS action in case of extraordinary behavior / 245 <https://github.com/KantaraInitiative/wg-uma/issues/245>: Location Constraints / 224 <https://github.com/KantaraInitiative/wg-uma/issues/224>: RS Notifies AS or RO of Access / 63 <https://github.com/KantaraInitiative/wg-uma/issues/63>: Audit logs to support legal enforceability / 24 <https://github.com/KantaraInitiative/wg-uma/issues/24>: Possible to audit host's compliance in giving access based on a legitimate active permission from the AM? - How many use cases? - Which are in our scope for V2.0 or out (e.g., separate modular specs that a V2.x could call out as an optional or required endpoint as part of the protection API or something)? - AIs for next steps? - 260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers - Is this in scope for V2.0 or out (e.g., a third-party extension that we could consider for a V2.x), considering the additional detail provided in email <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/cUHEEQNAj…> ? - AIs for next steps? (don't do heavy design today) - "Dipstick check" on the RReg issues: - 269 <https://github.com/KantaraInitiative/wg-uma/issues/269>, 270 <https://github.com/KantaraInitiative/wg-uma/issues/270>, 271 <https://github.com/KantaraInitiative/wg-uma/issues/271>, 272 <https://github.com/KantaraInitiative/wg-uma/issues/272> - Easy issues to close by *Tue Jan 24* if no comment by then: - 256 <https://github.com/KantaraInitiative/wg-uma/issues/256>: Naming and concepts - Proposal: Define "claim token" in the spec - AOB *Eve Maler* Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0