- WG-UMA - mailman.kantarainitiative.org

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

271: Add 'description' to scope document / 271: Add description to resource description
by Eve Maler 17 Jan '17

17 Jan '17

271 <https://github.com/KantaraInitiative/wg-uma/issues/271>: Add 'description' to scope document 272 <https://github.com/KantaraInitiative/wg-uma/issues/272>: Add description to resource description Mike suggests a definition of the property, in the scope case, could be something like this: description OPTIONAL A human-understandable explanation of what granting the scope means. So these would be the long-form explanation vs. the name. Often such fields are paired together. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

17 Jan '17

- 270 <https://github.com/KantaraInitiative/wg-uma/issues/270>: Resource Registration Document: 'uri' should be an array / examples Please go and read, and comment on, this short but thought-provoking issue. FWIW, in some HEART-related discussions, the question of when, why, and how to register resources and the efficiency of doing so have been coming up, so I thought this was timely. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

17 Jan '17

- 269 <https://github.com/KantaraInitiative/wg-uma/issues/269>: Resource Reg Section 2.1: "URI MUST resolve to a scope description document" This is the first of a series of RReg issues I'll send in email, thanks to Mike S's reportage (thanks for that). Mike asks: "I was contemplating the above... and wondering what you mean by "resolve." If the URI is a URN, then you just mean it must be defined somewhere? And why can't the URI be a collision-resistant string?" Also: What if there is a scope description document, but the link fails, what happens? What if there's no document at all? What are the error conditions? What are the fallback mechanisms? Should this really be a MUST, after all? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

260: Cascading authorization servers: more detail
by Eve Maler 17 Jan '17

17 Jan '17

Here is the additional information I received about this proposal, captured as issue 260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers. Please see both the description and the attached swimlane. ==== Please find attached a detailed sequence diagram for the cascaded authorization’s main flow —i.e. when both upstream and downstream ASs are involved. As for introspection, it is an interesting case. I think the downstream AS must be able to adapt/modify the upstream permissions (scopes) according to its overarching policies and combine its own permissions (scopes) with those received from the upstream AS using some kind of a configurable “introspection combining strategy.” Alternatively, it can be left to the implementers to simply decide what they want to do —although I think it must be noted in the specs as an important decision that the downstream AS must make. The decision on the validity of the RPTs is similar. I think the validity of the downstream RPT must not exceed the validity of the upstream RPT on which basis it is issued, but again, this is something that can be left to the implementers. In my current demo implementation, the downstream server simply passes on the same permissions (scopes) from the upstream server and the introspection results trickles down unmodified. But this is just a decision I made to keep things simple for this demo, while setting aside a module for “introspection combining” which currently is a simple identity function. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Set Math Discussion
by Justin Richer 17 Jan '17

17 Jan '17

I’ve been working on the set math problem and I’ve been trying to lay out scenarios using this spreadsheet to help me sort my thoughts: I’ve left a bit of space in the spreadsheet for additional combinations and use cases I might have missed, so please chime in and we can figure out an algorithm that we can all agree on. I can send out the .xlsx file if people care to play with it at home. So we’ve got six sets of scopes to deal with here, and they’re somewhat independent of each other. ClientReg - client registers for these scopes at the RS RSTicket - RS requests a ticket with these scopes ROPolicy - RO sets a policy with these scopes (and it’s fulfilled by the RqP for our purposes) ClientReq - client requests these scopes at the token endpoint RSReg - RS registers these scopes at RS setup time PrevRPT - client presents a previously-held RPT that’s got some other scopes on it and it’s trying to augment that with new scopes And finally what the token includes: RPTResult - the sets that the resulting token includes on output The one direct relationship seems to be that: ROPolicy = subset(RSReg) Because otherwise the RO could set scopes on a resource that the resource didn’t register, which doesn’t make sense to me. That’s the error in column “F” above. It’s clear to me that “ROPolicy” is a limiting set, in that if a scope is NOT in that set, then it is not in the result. In other words: RPTResult = subset(ROPolicy) That’s column D, and nearly any other combination without ROPolicy doesn’t let the scope go through, with one exception: if it’s in PrevRPT, it gets carried through no matter what. But in particular, that, I believe, is an AS decision on whether it wants to honor previous RPTs at all. That’s why I’ve coded those K, L in green. This also means that RSReg is also a limiting set, due to transitive subset operations: RPTResult = subset(RSReg) We have both the client and RS request scopes for the token at runtime in their parts, and it makes a lot of sense to combine them. So we get a working set of: Requested = union(ClientReq, RSTicket) We have an open question with what to do with column I: if a client hasn’t requested a scope, and a ticket didn’t request a scope, but the client registered for a scope, do we include it or not? We could choose to either ignore it and leave it out entirely; or add it in, and if it passes ROPolicy then we’ll pass it through to the token. These were the options we were discussing on the call on Thursday. Ignoring it here would effectively ignore the client’s registered scopes entirely, which is valid. The alternative would be coded something like: Requested = union(ClientReg, ClientReq, RSTicket) This could also be done conditionally, like the case where the client didn’t specifically request anything: if (empty(ClientReq)) { Requested = union(ClientReg, RSTicket) } Or if the client or ticket didn’t request anything: if (empty(ClientReq) && empty(RSTicket)) { Requested = ClientReg } So my proposed implementation would be something like this horrible pseudocode: if (ROPolicy is not subset(RSReg)) { throw error and fail <<sanity check>> } << the requested set is made up of the client’s request to the token endpoint and the RS’s request during the ticket issuance step>> Requested = union(ClientReq, RSTicket) << if nothing’s been requested, maybe the client’s registered for something we can default to >> if (empty(Requested)) { Requested = ClientReg } << finally, we take the requested scopes and filter out anything not in a matched policy, and add in anything from a previous RPT if it’s there >> RPTResult = union( intersection(Requested, ROPolicy), PrevRPT) I’ve tested a little bit of this with the following python truth table code: from truths import Truths print Truths(['ClientReg', 'RSTicket', 'ROPolicy', 'ClientReq', 'RSReg', 'PrevRPT'], ['(((ClientReq or RSTicket) if not (ClientReq or RSTicket) else ClientReg) and ROPolicy) or PrevRPT']) This seems to match up to expectations on a quick inspection, but I’m potentially missing something. Hopefully this makes sense, and this reflects my current thinking on this topic. I have almost certainly missed some use cases and might have some cases that don’t reflect reality. — Justin

1 0

Draft minutes of UMA telecon 2017-01-12
by Eve Maler 13 Jan '17

13 Jan '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-12 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-01-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-05>: APPROVED by unanimous consent. UMA V2.0 work *Set math:* Justin intended for ROPolicy to stand for the result of AS postprocessing of any policy conditions with which it has been configured. George intended for ROPolicy to stand for policy conditions prior to any AS processing. This may be moot for the math. Justin considered the math to be contextual to the resource set because of his implementation outlook, but George wants to ensure that, if the ROPolicy isn't sufficient to meet the requested policy, need_info (or "worse", definitive failure) is produced. Eve notes that "RO" policy is really a set of policy conditions that could have come from a collaboration between the RO and the AS; see, e.g., the TTL section <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-11.html#rfc.section.…> . In George's example, Alice has policies that should result in *Bob* not getting access to *download* because he's not a family member. Let's think of *ROPolicy* instead as *PolicyResults*, (or even *AuthorizationProcessResults*?) and the value should be just *(view, share)* . Given Justin's interpretation that we're accepting, George's example set math stays the same, and the "determine which scopes are in play" section changes like this (*download* got removed, with no net change to the bottom line), and it should say "*...based on claims collected and the authorization assessment performed*": Scopes = intersection(Requested, ROPolicy) Scopes = intersection((view,share,print),(view,share)) Scopes = (view,share) James proposed ClientRegisteredDefaults vs. the original OAuth ClientReg as a convenience/clarification. George thinks we don't need this because it's more of a burden on the client. The client knows it's dealing with whatever API and its scopes. Registering ahead of time lets it reduce its interactions at access attempt time. If we drop ClientRegisteredDefaults, it's incumbent on the client to register ahead of time. Looking at the steps: 1. This now becomes: *Requested = union(intersection(ClientRegistered,ClientRequested), RSTicket)* If ClientRegistered OR ClientRequested is null, then RSTicket becomes all-important because the others won't get the client anywhere. If ClientRequested contains anything not previously in ClientRegistered, it gets dropped on the floor. 2. This is all part of the assessment process. Combine steps 2, 3, and 4 because they're all in this general area. 3. The pseudo-spec-text would change to say "*...scopes for which RqP (and client) has satisfied authorization requirements*" or something like that – with claims? figure out wording. We need a phrase that stands for the RqP-and-client. Would "requesting side" do? 4. This is the part of authorization assessment the AS would do if it's preparing to give a need_info error or maybe a request_submitted error (?). If it's preparing to give one of the other errors, it can dump out to those. 5. This would change to be* error*. 6. This would change to be *success*. This will need, in addition, the math that says what to do in the case that a previous RPT was supplied and was returned upgraded. We have consensus on all the set math modulo previous-RPT handling. Editing instructions: - Think up a phrase for "requesting side" and apply where necessary - Add spec text for everything but *previous-RPT set math*. - Implement the #264 decision where applicable. - Add to the extension grant type registry <http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#par…> *AI:* Everyone: Read the new set math spec text carefully ASAP when it's available, and implement if you can. *264 <https://github.com/KantaraInitiative/wg-uma/issues/264>: Authentication-related error details:* Justin ran through the swimlanes he provided in the issue thread: with a local user <https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgVU1BIFN0ZXAgVX…> and with a remote IdP, using OIDC's auth code as example <https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgVU1BIFN0ZXAgVX…>. George asked about registration. If the RqP doesn't yet have an account, they'd have to do that step, right? Yes. Mike's question in the thread had been about login. There's a distinction between the (UMA) client and the AS as a claims client/RP. Eve insists on getting it on the record [image: (smile)] that pushed claims with secondary audience fields using pre-established trust are a legitimate, on-label use of ID tokens. No disagreement, but also noted that doing a lot of hinting around what other claims to push is not likely to be used in such ecosystems. Using redirect_user immediately on failing a plain request for an RPT is likely for the case where the AS intends to handle all the claims collection. We have the UMA Implementers' Guide, where we could discuss things like achieving strong authentication. Or we could provide an example in the spec of profiling down to ACR values. *AI:* Eve: Ask Mike Pegman if he has the strong authentication use case. *(The official call ended and we continued for a short while.)* *Authorization interface and UMA grant:* The spec is currently schizophrenic. The whole authorization process is the UMA grant, not just the client's interaction with the token endpoint. This means Figure 1 is wrong and Sec 3.6 is right. The preconditions for starting with redirection are that the client needs a ticket and the AS has to have statically declared the claims interaction endpoint (plus all the other stuff for entering Sec 3.6, which is the generic stuff for starting with approaching the token endpoint). *AI:* Eve: Seek stylesheet help from Maciej/Oliver (and/or the xml2rfc list?). *254 <https://github.com/KantaraInitiative/wg-uma/issues/254>: Hashed claims discovery:* Eve is wondering whether, in certain ecosystems where pushed claims have been pre-negotiated a la SSO with attributes, hinting specifically about needed claims is being used/going to be used. We should ask around about whether this is being used. This bears on the question of hashed claims discovery as a feature for consideration, since it could be added as an extension or in a V2.1. As an in-band hint, it's there to be useful to wider ecosystems. And if the AS were to say redirect_user on failing client-provided hints, that would suggest that a really colossal closed-ecosystem failure could be mitigated by something kind of surprising on the AS's part. *AI:* Eve: Ask for instances of required_claims usage. *AI:* Eve: Send out some new cascading authorization server information from VA. AI: Eve: Send emails for the next issues to discuss. 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. Maciej 6. Sarah Non-voting participants: - George - Justin - JohnW - James - Colin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

No Legal subgroup telecon tomorrow
by Eve Maler 12 Jan '17

12 Jan '17

We've succeed in finding the expertise we were looking for to work on our precursor deliverables, in batches, so what I suggest is that we wait until we can take a look at batch #1 before meeting again. I'll keep an eye out for such news, and *each Thursday* I will either *announce the news in the form of an agenda* or *cancel the Friday call*. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-01-12 (note: new drafts are up)
by Eve Maler 11 Jan '17

11 Jan '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-12 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-05 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-05> - 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 11 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-11.html> and RReg is up to 04 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-04.html> - Issues closed: 108 <https://github.com/KantaraInitiative/wg-uma/issues/108>, 234 <https://github.com/KantaraInitiative/wg-uma/issues/234>, 249 <https://github.com/KantaraInitiative/wg-uma/issues/249>, 261 <https://github.com/KantaraInitiative/wg-uma/issues/261>, 262 <https://github.com/KantaraInitiative/wg-uma/issues/262>, 268 <https://github.com/KantaraInitiative/wg-uma/issues/268> - Also tried out Justin's wording for how the AS and client handle invalidating/revoking an old RPT when the AS hands back a new RPT – see Core rev 11 Sec 3.6.6 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-11.html#give-rpt> - *Please see new issues!* We'll discuss as necessary next week; please comment online: - 271 <https://github.com/KantaraInitiative/wg-uma/issues/271>: Add 'description' to scope document - 270 <https://github.com/KantaraInitiative/wg-uma/issues/270>: Resource Registration Document: 'uri' should be an array / examples - 269 <https://github.com/KantaraInitiative/wg-uma/issues/269>: Resource Reg Section 2.1: "URI MUST resolve to a scope description document" - Issues to *discuss and close on this call*: - 264 <https://github.com/KantaraInitiative/wg-uma/issues/264>: Authentication-related error details (quick) - 254 <https://github.com/KantaraInitiative/wg-uma/issues/254>: Hashed claims discovery (quick) - 266 <https://github.com/KantaraInitiative/wg-uma/issues/266>: Set math (hopefully we'll have some spec-like wording to guide us further by tomorrow) - 256 <https://github.com/KantaraInitiative/wg-uma/issues/256>: Naming and concepts, specifically authorization interface vs. UMA grant concept - Issues to *discuss and hand out assignments for*: - 256 <https://github.com/KantaraInitiative/wg-uma/issues/256>: Naming and concepts, specifically a definition for and handling of the access token/claim token situation - 263 <https://github.com/KantaraInitiative/wg-uma/issues/263>: Claim token profiling / 119 <https://github.com/KantaraInitiative/wg-uma/issues/119>: Create an IANA registry for URIs that stand for claim token formats - 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? - 260 <https://github.com/KantaraInitiative/wg-uma/issues/260>: Cascading authorization servers - Easy issues to *close by Tue Jan 7 if no comment by then*: - 256 <https://github.com/KantaraInitiative/wg-uma/issues/256>: Naming and concepts, specifically whether to rename PCTs - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0