January 2017 - WG-UMA - mailman.kantarainitiative.org

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 22 Jan '17

22 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 19 Jan '17

19 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 19 Jan '17

19 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

Core rev 12 is up
by Eve Maler 18 Jan '17

18 Jan '17

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-12.html Set math (except for "previous RPT" logic) is implemented! Things to read very carefully, please: - Section 1.4.2 -- that's the "money" content - The transplanted stuff at the end that used to live in the Authorization Assessment subsection in Section 3.6 (it probably doesn't need to be in the spec anymore) - Section 9.4 (could be done all wrong) With how we've got this done now, I suspect "previous RPT" logic won't be all that hard to express. And even if the current logic is wrong, we now have a good handle on how to express ourselves (thanks to Justin, George, James, and others...). I'll get an agenda out tomorrow. Do also please cast your eyes over the emails I sent earlier today, and their corresponding issues. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

The "shoebox" issues: consent and notice and information sharing matters
by Eve Maler 17 Jan '17

17 Jan '17

We've collected a series of issues at the nexus of #trust, #ROctrl ("RO can meaningfully throttle access that RS gives"), and #ROctrl ("RS can throttle access beyond AS-imposed limits"), and "consent and notice and information sharing matters" that we have nicknamed *shoebox* thanks to Andrew Hughes. Here are the relevant issues; you can see some of them go way back in time! - 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? These issues variously detail use cases in the UMA context. This mega-issue is connected to various other efforts, including our own UMA Legal subgroup (see particularly these notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…>), the Consent and Information Sharing WG's Consent Receipt work (note that the CR spec has just gone out for Public Review on Jan 6), FHIR (for its "Consent" structure), and possibly others. Consent records and transaction records and signed notifications of exceptions, etc., are usually conceived of as being useful to store in a secure transaction repository of some kind. Some questions: - Given that UMA isn't alone in this, should we even be talking about UMA-specific functionality? Are we talking about an AS hosting a "shoebox endpoint" because an AS is the right place for such a thing to be hosted, or because a server that happens to be an AS is also a "shoebox endpoint server" (or something like that)? What is UMA's differential interest? Has anyone in other groups proposed something concrete around a "shoebox endpoint"? - There are people working on putting consent/transaction receipts on blockchains. ("Drink!") Should we be working on centralized places to store notifications/records? - UMA Legal has figured out what it wants to do, to a point, in the legally enforceable world. How machine-readable can the proposition get -- at least for our purposes in UMA2? Please feel free to add your own questions (or answers)... *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 17 Jan '17

17 Jan '17

273 <https://github.com/KantaraInitiative/wg-uma/issues/273>: Remove reference to "user" in List Resource Descriptions This one is perhaps a bit philosophical... Please take a look. I would love to be able to discuss this and the others in this series "asynchronously" as much as possible. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0