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

Notes from UMA Legal telecon 2017-07-28
by Eve Maler 28 Jul '17

28 Jul '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-07-28 Attending: Eve, Kathleen, Tim, Bjorn, Mark (Oops, a bug in the diagram, the sharing scenario labels need to be reversed.) The nature of the CO’s access to the resource is determined by the TOS between the CO and the RqP, particularly in the case of a human RqP (Individual scenario). The client app will have certain access-getting capabilities, and will represent those to their user. Who is paying whom for what? In the case of an Individual RqP using a client app, quite often the individual downloads a free app (possibly with in-app purchases) or pays for an app (this would be for mobile apps, including those associated with smart devices, or even for desktop apps). In the case of a Legal Person using a client app, more often there won’t be TOS as such but the client will be developed in-house or done as work for hire by a mobile app dev house. In both cases, an ASO would tend to be in control of which clients they work with because an AS gets to be “picky” about clients -- clients always bring security risks. But different ecosystem pressures can lead ASO’s to be more open or closed. The DirectTrust initial trust bundle (trust framework) was deemed not safe enough so they had to develop a second one. No matter how "dynamic" the process becomes, and the OAuth Dynamic Client Registration protocol is making it quite dynamic, there are reasons for an ASO to potentially want the process to include manual steps, such as lawyers or accountants or other certifiers to get involved. This is precisely where trustmarks and whitelist mechanisms of various sorts are intended to reduce the friction of such manual mechanisms. A client developer could then include a signed assertion in their "SSA" (software statement assertion), which an AS could consume. The technical artifact we could *eventually potentially* take advantage of here is something in the SSA for dynamic client registration for UMA certification. There's a nice older diagram, looking like a train track or puzzle pieces, that shows the various TOS's sticking everything together. What might be better is two train tracks, for the RO and for the RqP, where they build up enough relationships with the RSO/ASO and CO/ASO respectively through the legal/technical artifacts and merge. Ultimately we could show them diverging as the licensing relationship gets torn down. (This would be when we know that we've reached the end of designing the legal framework!) We agree that our goal is to have the legal framework point to the technical artifacts (e.g. as we did in the old Binding Obs <https://docs.kantarainitiative.org/uma/draft-uma-trust.html>), and this is sufficient for now. Various individual tools in the toolkit will ultimately have technical artifacts point to legal artifacts (e.g. URLs containing hashes of the specific versions of text etc.). This latter approach is all implementation-dependent, and so we don't want to optimize prematurely. We should try a) connecting the definition of Data Subject to Resource Owner, to justify why to include Data Subject, or otherwise drop Data Subject, and b) drop Requesting Party Agent and include "with the legal authority to seek access" to Requesting Party, or not drop RqPA and figure out how to square the circle. [image: (smile)] See the list below, and deliverable #1 for use cases! That rationalizes the two halves of the licensing end-to-end relationship. The legal versions of the sharing scenarios should actually look like this: - Individual-to-self (this is potentially interesting legally because Alice tends not to want to impose onerous licensing controls on herself, only on the CO) - Individual-to-Individual - Individual-to-Legal Person (maybe this breaks down along the lines of different business models) - Individual-to- (do we want to consider "Requesting Party Agent" as a role because of use cases?) WRT Data Subject, we could treat that as a whole separate mapping exercise: DS, DP, DC. Should we do that separately? A topic for another time. The ONC Trust Exchange Common Agreement work could potentially point to this work to get to a more dynamic model vs paper-based. *AI:* Eve: Reach out to Domenico to get his help on creating new diagrams that drill into these detailed relationships. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: Legal telecon today
by Eve Maler 28 Jul '17

28 Jul '17

Usual Bat time and channel. We'll be working off these slides <https://docs.google.com/a/meshfire.com/presentation/d/1I12agEsfaJK3LEiJyROr…>. (Not sure if just providing this link will work -- please ask for access and I will grant it.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-07-27
by Eve Maler 27 Jul '17

27 Jul '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-27 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-07-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-20>: Deferred. UMA 2.0 work 337a <https://github.com/KantaraInitiative/wg-uma/issues/337>: RFC 7519 <https://tools.ietf.org/html/rfc7519#section-4.1.4> just says these three claims are optional. (Right now we are being inspired by the claims and not registering for JWT claims specifically.) Cigdem, along with Justin, argued for removal of an explicit statement (as we still do for exp) saying exactly what it means when the permission-level parameter is absent. If we don't say, then Eve's interpretation is that "the AS isn't claiming anything" about that semantic. It's up to the AS, presumably, what it means, but that's part of its prerogative. Mike wonders what AS wouldn't include a value. We already say what happens if it has a value at variance with the permission-level value. If we take away the exp "no-value" statement of "never", then the AS has the incentive to do the right thing in any case (vs, say, deciding on a super-secret nbf value of Jan 5, 2020 at 03:59:53). That doesn't help anyone! *Consensus to remove the exp statement.* 337c <https://github.com/KantaraInitiative/wg-uma/issues/337>/d: The suggestion is to 1) make it a MUST for the AS to require public clients to register claims redirection URIs (Grant Sec something), with the rationales that it matches 6749 Sec 3.1.2.2 <https://tools.ietf.org/html/rfc6749#section-3.1.2.2> and it's more secure (*we have consensus on this*), and 2) to request registration of a metadata field to the OAuth dynamic client registration metadata registry <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#cl…> (Grant Sec 2). Would we also want to request registration of a metadaata field to the OIDC dynamic client registration metadata registry, or is it all the same? It appears to be the former. *We have consensus that adding the metadata field is sensible too*, with the rationale that it gives a concrete way to register the URI and removes friction from interoperable dynamic registration. But we do want to check with Justin (who is the designated expert for this metadata registry). This would require a new section or subsection in Grant akin to the AS metadata section. AI: Eve: Ping Justin re claims_redirect_uri metadata field. 337f <https://github.com/KantaraInitiative/wg-uma/issues/337>: We discussed Cigdem's proposed example, which starts with a resource request of album and a permission ticket containing photo1 and photo2, which adds a level of trickiness that may be distracting for the point at hand. We think the calculation seems pretty simple regardless; the AS is "dumb" with respect to resources, even though scopes are resource-bound, so it does the calculatiion the same way regardless. Only the RS knows resource relationships. The AS does an expansive scope match on the client's behalf because the client is "dumb" with respect to resources. AI: Eve (hopefully with Cigdem's input): Come up with a hybrid example that has two resources in the permission ticket. UMA logo Deferred. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Andi 4. Maciej 5. Eve 6. Mike Non-voting participants: - James - Kathleen - Robert - Scott - Bjorn *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

For the WG's consideration: open issues
by Eve Maler 26 Jul '17

26 Jul '17

Grant rev 06 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html> and FedAuthz rev 06 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.…> are now up! These contain implementations of all the agreed-to and purely editorial solutions to Public Comment (and a couple of minor post-Public Comment) issues to date. Issues #335, #337, and #339 (and various sub-issues) are worth discussing, and I'd like to do that in tomorrow's call. I've put some thoughts into the threads already to kick things off. Please feel free to respond in this thread prior to the call! In approximate order of importance: 1. 337a <https://github.com/KantaraInitiative/wg-uma/issues/337>: iat and nbf in the token introspection response don't say what should happen if the permission-level value is missing, while exp does <https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.…>. We started discussing this last week <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-20> and didn't quite come to a conclusion (it was shaping up to be "remove what we say even in exp"). Can we decide this quickly? 2. 337c <https://github.com/KantaraInitiative/wg-uma/issues/337>/d: It's been proposed that we register a client metadata element in the "OAuth Dynamic Client Registration Metadata Registry" so that claims_redirect_uri can be formally dynamically registered, and also to make it REQUIRED for public clients to register these URIs. Thoughts? 3. 337f <https://github.com/KantaraInitiative/wg-uma/issues/337>: This was a request for more set math clarification, specifically around what happens if there are multiple permissions in the permission request. To me it was obvious that "it all works the same", but skepticism was expressed. :-) Please see my example in the GitHub thread. Can we riff off that as a solution? 4. 337b <https://github.com/KantaraInitiative/wg-uma/issues/337>: Is my suggestion a good one to add a statement that the client MAY be confidential or public, for clarification? 5. 339 <https://github.com/KantaraInitiative/wg-uma/issues/339>: It seems our description of object vs array in permission requests came out somewhat ambiguous. We have an opportunity here. Should it be possible for RS's to choose which way they request a single permission, with the AS picking up the slack? 6. 335c/d <https://github.com/KantaraInitiative/wg-uma/issues/335>: It was suggested to break out Grant Fig 1 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html#high-…> into an RO vs RqP flow to show asynchronicity, and then also the latter to be broken out into claims push and interactive claims gathering flows. Theoretically I liked the ideas, but trying to implement them and getting some feedback, I didn't anymore. I think devs will prefer a single summary diagram with all the entities. Thoughts? 7. 337g <https://github.com/KantaraInitiative/wg-uma/issues/337>: I'm recommending no change regarding further protecting permission tickets as being single-use. Sound good? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-07-27
by Eve Maler 26 Jul '17

26 Jul '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-27 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-07-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-20> - UMA V2.0 work: - Disposition of Comments <http://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+of…> /GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> /Grant swimlane <https://www.websequencediagrams.com/files/render?link=GDUuGPibcbXrR5uWBSQP> , FedAuthz swimlane <https://www.websequencediagrams.com/files/render?link=tGft5o5ErGvUWj4X3o-O> /Release Notes <http://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes> /UIG <http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui…> /Wikipedia <https://en.wikipedia.org/wiki/User-Managed_Access>/Grant rev 06 (forthcoming)/FedAuthz rev 06 (forthcoming) - The Disposition of Comments is the best overall way to drill into what's been done and what remains - Please focus on #335, #337, and #339 – and let's get these all done in one session, so please do some homework before the call - Candidate motion (let's target next week when we'll have had more time to review the latest decisions): "Approve UMA 2.0 Grant rev *nn* and FedAuthz rev *nn* as amended by the instructions of UMA telecon 2017-xx-xx as Draft Recommendations and forward them to the Kantara Leadership Council to request immediate certification for an All-Member Ballot as Recommendations." - UMA2 logo discussion - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Named permission objects
by James Phillpotts 24 Jul '17

24 Jul '17

Hi all, Eve sent me an email off-list last night asking "Are we going to be sorry we don't have a named object for a single permission?" With clarification this morning, it turns out she was talking about the token introspection endpoint :) You'll remember the response currently looks like: { "active":true, "exp":1256953732, "iat":1256912345, "permissions":[ { "resource_id":"112210f47de98100", "resource_scopes":[ "view", "http://photoz.example.com/dev/actions/print" ], "exp":1256953732 } ] } With a bit more discussion, the only thing I could see as potentially useful was to have permissions as an object (instead of array), and use the resource_id as the key in the object. To do this, we'd have to then make its value an array so that if you have multiple different scopes with different expiry times, they could be expressed effectively, so: { "active":true, "exp":1256953732, "iat":1256912345, "permissions":{ "112210f47de98100":[ { "resource_scopes":[ "view", "http://photoz.example.com/dev/actions/print" ], "exp":1256953732 }, { "resource_scopes":[ "edit" ], "exp":1256953750 } ] } } I'm by no means convinced that this is very much more useful than the current version, and is thoroughly backwards-incompatible, but the object structure could be useful if RPT permission arrays were to get very big. Thoughts? Cheers James

2 1

UMA2 logo proposal (please do not use!)
by Eve Maler 21 Jul '17

21 Jul '17

Here is Domenico's proposal. Let's not use any proposals/drafts till we settle on something. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl Preview attachment UMA_logoV2b.pngUMA_logoV2b.png365 KB <https://mail.google.com/mail/u/0/?ui=2&ik=1004c2bba3&view=att&th=15c784379e…>Preview attachment UMA_logoV2_explained.pngUMA_logoV2_explained.png495 KB <https://mail.google.com/mail/u/0/?ui=2&ik=1004c2bba3&view=att&th=15c784379e…>

7 20

Notes from UMA Legal telecon 2017-07-21
by Eve Maler 21 Jul '17

21 Jul '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-07-21 Attending: Eve, Kathleen, Tim We started looking at chart 6 (not sent in email). Tim would like to ensure that we get the pairwise (or more) relationships, legal devices, and artifacts locked down so that he can revise the definitions. The column mentioning "pairwise" should probably take that word out because some of the artifacts definitely represent more than two of the roles. A *license*, versus a *contract* specifically, gives flexibility around number of parties and promises. It's about tracking permissions. Some permissions are given with some conditions. The license gets revoked if the conditions aren't kept. A license scales better than a contract as a legal mechanism. (Kathleen refers to the licensing model as essentially an authorization model.) A DURSA (data use reciprocal service agreement), from healthcare, is an example of a surrounding contract that could be used to encompass the kind of license we're talking about. Many of the use cases we've collected – a nanny collecting kids from daycare, giving someone access to a connected car – show that there's a desire to ensure a contractual apportionment of liability across to a requesting party in addition to licensing. If this were a contract, the RO Alice would be the offeror, the resource access permissions would be the consideration, and the RqP Bob would theoretically be the offeree – but where is the acceptance part? In the technical layer of UMA, Bob might not have acted positively at all to get access. His client software might have "pushed" claims about him without any action on his part, Alice's AS might issue a PCT to his client that represents claims previously collected and the client subsequently "pushes" that PCT back, but that happens silently. Does that constitute acceptance? Do we have to build that into our model clauses? Using a licensing model, RqP Bob *doesn't* have to accept, and any overarching contract layers could build that in only if they want to. Developing contractual-level tools is out of scope for us. The term "access contract" came from UCITA law. Do we want to use it? It appears in the role definitions, but should we step back from it? Actually, this is between the RO and ASO. So it appears on the wrong line; it should be on the RS-ASO line, not RO-RSO. Or was it correct after all? Are the RSO and ASO both parties to the access contract? The RO becomes *the* licensor, and do the ASO and RSO both become the sub-licensors? It would be helpful, in the "Legal Relationship" column, to always state "*so-and-so* is the *role* for *whom-downstream* of *what* on behalf of *whom-upstream*". E.g., "RSO is sub-licensor on behalf of RO". Maybe we can even construct the columns so that each variable gets filled in, in order, to form a "sentence"? The RO is at the "head" of the relationships. The RO owns the access rights. (In US healthcare, under federal law, a patient owns right of access.) The ASO-CO artifact of OAuth client credentials is only related to that pairwise relationship (not to RqP BoB or to the PCT; this should be relegated to a separate row). It could be related to a contract, say, ToS. It's a *potential place* where conditions that are protective of Alice *could* go, e.g. to ensure that the client (later interacting with Bob, e.g. sharing Alice's data, storing Alice's data, etc.) acts in a way that is aligned with Alice's interests. At the end of the day, the legal aspects have to match the UMA flows and artifacts exactly. *AI:* Eve: Try to do an edited matrix in GSlides form for the group. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: Legal telecon tomorrow
by Eve Maler 20 Jul '17

20 Jul '17

8am PT/11am ET http://join.me/findthomas We'll have fresh role definitions, mappings, and diagrams. Good times! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-07-20
by Eve Maler 20 Jul '17

20 Jul '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-20 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-06-29 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-06-29> and UMA telecon 2017-07-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-13>: APPROVED by unanimous consent. UMA 2.0 work Is the right distinction in the Disposition of Comments document <http://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+of…> "Would the change potentially cause anyone to raise a new IPR issue or not?", rather than "Is it 'editorial' or 'technical'?" So if something goes from, say, MUST to something weaker (SHOULD or MAY), that would (could?) raise IPR issues. But just clarifying something that was unclear in the Draft Recommendation would presumably be editorial. Andrew asks: If no one makes a necessary claim, does it matter? "The tree has already fallen in the forest." [image: (smile)] The WG will make its case in the comment log where anything seems marginal. Finalizing the specs Sample motion when the time comes: "Approve UMA 2.0 Grant and FedAuthz revs 06 as amended by the instructions of UMA telecon 2017-xx-xx as Draft Recommendations and forward them to the Kantara Leadership Council to request certification for an All-Member Ballot as Recommendations." #332 <https://github.com/KantaraInitiative/wg-uma/issues/332>: If the AS is "basically" expiring a previous PCT when it goes to a new authorization process, should we say it MUST? It's more like any previous PCT from a previous assessment has be superseded/overcome by events (namely, "one process/one ticket lifecycle"). How explicit do we need to be about this, for implementers to understand this clearly? We're inclined not to add more refresh token-like text, despite the suggestion, because it's a little too prescriptive, and we agree with the commenter's interpretation that *"I would say, that according to the current version, the AS can really choose, whether to expire PCT when issuing a fresh one and the client is not forced to discard the old one."* Using this behavior, the AS and client would each simply have old PCTs from previous authorization processes and could issue/use them for any future authorization processes they want. The wording throughout Grant doesn't prevent this; we checked. Do we now need to consider *clarifying* that this "multiplicity" of uses is okay? Is it ambiguous the way things stand? That is, Eve's reading, in the issue, of "basically" expiring is not required. Justin, James, and Mike (Yuriy) all interpret the current text to be okay with more than one-time use. Optimization of future experience is basically the rationale for PCTs, so this makes sense. Andi brings up the security and privacy considerations; we do cover these, and revocation is also covered, so we're good there. And the AS can always expire at will. No change in the wording. #337 <https://github.com/KantaraInitiative/wg-uma/issues/337>: - exp/iat/nbf: There was an original reason for the "split" logic of talking about what happens when exp is absent vs the others. "If the parameter is absent, the permission does not expire." We tried to mean that the permission could live on past the token lifetime, but this is nonsense. [image: (smile)] What if we delete this sentence, keep the three other sentences allowing the token-level value(s) to take precedence (or refactor that sentence out to the token level), and live with the fact that we don't say anything about the absence of the OPTIONAL values? What is our intent about implementers' behavior? The RS's behavior is about cache control. The AS is likely not to hand back something already expired. Everything beyond active=true is a hint. So the RS could just try again if it didn't get what it wanted. - Did a quick tour through the other items. Most should be easy for disposition. UMA logo ideas AI: Eve: Email out Domenico's first logo idea. Let's send thoughts his way. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Andi 4. Maciej 5. Eve 6. Mike Non-voting participants: - James - Justin - Andrew *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA telecon 2017-07-13
by Eve Maler 19 Jul '17

19 Jul '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-13 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2017-06-29 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-06-29>: Deferred. UMA 2.0 work *#328 <https://github.com/KantaraInitiative/wg-uma/issues/328>:* how client-contributed scopes are mapped to resources during authorization assessment: Eve's first iteration was "Treat each scope in ( *ClientRequested* ∩ *ClientRegistered*) as applying to all matching resource-bound scopes in *PermissionTicket*." She's thinking that it would be more accurate to say something like "...all scopes associated with resources appearing in *PermissionTicket*", and then we could add ", with the scope matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison)." Let's give this wording a try in context (published draft) and see if it makes sense there. #334 <https://github.com/KantaraInitiative/wg-uma/issues/334>: the IANA registration request for the JWT permissions claim and its constituent parts: Justin suggests that we need to have a paragraph talking about the security and privacy considerations of putting this information into the token vs. an introspection response, because the token is exposed to the client. The permissions claim and its sub-claims give tools directly usable by those who want to use the "local validation of self-contained tokens" path. Furthermore, the sentence in the Introduction is too modest: "Further*, with the use of token introspection,* authorization grants can increase and decrease at the level of individual resources and scopes." We can get rid of the italicized stuff. We have the following options: 1. Remove our registration request. 2. Specify how to "validate a self-contained token locally" in a separate document, with security and privacy considerations. Do we have enough real-world implementation experience to know what the considerations are? What is the sensitive information in the token? In a typical OAuth access token, there are typically scopes. In our permissions structure, there are resource IDs, scopes, expirations, etc. Also, there may be permissions that cross RS's. Is this sensitive wrt an individual RS too? Maybe it's trivial for an RPT that doesn't cross RS's, but not otherwise. Maybe it requires encryption per array object or something. Any considerations section would have to explicitly push responsibility onto the implementer. Eve speaks in favor of option 2. Kathleen notes that it's good to keep solving this properly on the roadmap. Sal agrees. James agrees. We have consensus. Editorial actions: Remove the IANA request for JWT claims, and edit the Intro sentence. Finalizing the specs Sample motion when the time comes: "Approve UMA 2.0 Grant and FedAuthz revs 06 as amended by the instructions of UMA telecon 2017-xx-xx as Draft Recommendations and forward them to the Kantara Leadership Council to request certification for an All-Member Ballot as Recommendations." UMA logo ideas tbs Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Sal 2. Maciej 3. Eve Non-voting participants: - Justin - Kathleen - Bjorn - Scott F - John W - Jin - James - Robert Regrets: - Domenico *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Agenda for UMA telecon 2017-07-20
by Eve Maler 19 Jul '17

19 Jul '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-20 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-06-29 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-06-29> and UMA telecon 2017-07-13 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-13> - UMA V2.0 work: - All GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> /Grant swimlane <https://www.websequencediagrams.com/files/render?link=GDUuGPibcbXrR5uWBSQP> , FedAuthz swimlane <https://www.websequencediagrams.com/files/render?link=tGft5o5ErGvUWj4X3o-O> /Release Notes <http://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes> /UIG <http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui…> /Wikipedia <https://en.wikipedia.org/wiki/User-Managed_Access> - Discuss proposed items from #337 <https://github.com/KantaraInitiative/wg-uma/issues/337> (forthcoming) - Discuss any proposed wording from #332 <https://github.com/KantaraInitiative/wg-uma/issues/332> (forthcoming) - Review in-progress Disposition of Comments document (forthcoming) - Finalizing the specs - When will we be ready to vote on progressing specs to the LC and then to All-Member Ballot? - UMA2 logo ideas - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-07-13
by Eve Maler 12 Jul '17

12 Jul '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-13 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-06-29 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-06-29> - Public Comment/IPR Review period concluded on July 12 at 11:59 UTC - UMA V2.0 work: - All GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> /Grant swimlane <https://www.websequencediagrams.com/files/render?link=GDUuGPibcbXrR5uWBSQP> , FedAuthz swimlane <https://www.websequencediagrams.com/files/render?link=tGft5o5ErGvUWj4X3o-O> /Release Notes <http://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes> /UIG <http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui…> /Wikipedia <https://en.wikipedia.org/wiki/User-Managed_Access> - Issues #326-#330 have been implemented - Please check out draft solution <https://github.com/KantaraInitiative/wg-uma/commit/1abd77b46e29fdd0d3e0b606…> for #328 <https://github.com/KantaraInitiative/wg-uma/issues/328>: how client-contributed scopes are mapped to resources during authorization assessment - Let's briefly discuss #334 <https://github.com/KantaraInitiative/wg-uma/issues/334>: the IANA registration request for the JWT permissions claim and its constituent parts - Several of the items in #337 <https://github.com/KantaraInitiative/wg-uma/issues/337> are worth discussing - If you want to review and weigh in on the other public-comment-period issues, please do it before the call - Release notes <http://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes> are getting more fleshed out; review (and contributions) welcome - Finalizing the specs - When will we be ready to vote on progressing specs to the LC and then to All-Member Ballot? - UMA2 logo ideas - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Several comments
by Guttner, Ondrej 12 Jul '17

12 Jul '17

Hi all, During the implementation of the standard, I came across several points I think needs to be cleared (at least to me, and I hope the reason is not my stupidity). I know the public comment period ends tomorrow, so I rather use this method of communication, so as, if there is something useful in the list, it is not missed. I wrote some of these remarks down during reading of the older versions, and now I tried to look whether it has already been changed, so excuse me, if I miss something, that was already added. https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.…: 1) 5.1.1: For exp, the behavior for absent value is defined. iat and nbf are missing definition for this state. Although it is quite intuitive (“if absent, the token-level value takes precedence”), might be worth include it to prevent possible misunderstandings. https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html: 1) 3.3: “The client has obtained OAuth client credentials from the authorization server, …, and is prepared to authenticate itself to the token endpoint if appropriate.” RFC6749 – 3.2.1: “Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in Section 2.3 when making requests to the token endpoint.” Doesn’t this mean, that in UMA, the client requesting at the token EP MUST always authenticate? The formulation from uma_grant 3.3 may lead to a conclusion there exists a situation in which it is not necessary to authenticate. 2) 3.3.2: If AS supports RFC7591, it MUST allow clients to register claims_redirect_uri (as mentioned in 2.), but it is not defined, how this parameter looks like (array?, space separated?) Shouldn’t it be better to have “claims_redirect_uris”? (RFC7591 defines redirect_uris also in plural). In RFC6749, redirection URI (which is similar from the security point of view to the claims redir URI) SHOULD require the use of TLS and MUST be registered for public clients. In addition, an incomplete redirection URI is enabled, and some other features. Wouldn’t it be beneficial to define claims redirection URI with reference to the definition of redirection URI? 3) 3.3.3: I personally would extend the first sentence to “ … of the claims redirection URI resolved according to the algorithm described in previous section using the …”. Otherwise, any preregistered claims redirection URI might be used (I know you would need to be an evil implementer to do this, but hey, who isn’t a bit?). 4) 3.3.3: The example response from AS is actually a request. 5) 3.3.4: This whole section makes the permission concept unclear to me. I suppose, that a request for RPT can contain multiple tuples (resource, scopes), where the scopes for each resource may be different. Section 3.3.4 puts an impression on me, that all these scopes sets are actually identical. Namely: “Let a set called PermissionTicket stand for the scopes associated with the permission ticket” does not distinguish between all the permissions that can be bound to the permission ticket. The example does not help in this either, as it concerns only a single resource. I’d suggest to add something like: “This authorization assessment holds for any permission bound to the permission ticket received by the AS.” Subsequently, it needs to be made clear, what happens if CandidateGrantedScopes < RequestedScopes for not all of the requested permissions. 6) 3.3.5: Described in https://github.com/KantaraInitiative/wg-uma/issues/332 7) 5.6: Permission ticket is similar in use to authorization code in OAuth (both are single use, may be transferred over plain HTTP), but the latter is influenced by additional security measure – if the same code is observed twice by AS, it should attempt to revoke all access tokens issued based on that code. Shouldn’t this be considered also for the permission ticket and relevant RPTs? I hope, it was not a loss of time for you to read through these lines. Kind regards, Ondrej Atos IT Solutions and Services, s.r.o. - CEO: Martin Sùra - registered in the Commercial Register of the Municipal Court in Prague, Sec. C, File 8954, Registered office: Doudlebská 1699/5, 140 00 Prague 4, Czech Republic, IÈ: 44851391, DIÈ: CZ44851391, Bank connection: UniCredit Bank Czech Republic a.s., Na Pøíkopì 858/20, 113 80 Praha 1, Acc. Nr. CZK: 1001885001/2700, IBAN CZK - CZ4627000000001001885001; Acc. Nr. EUR: 1001885095/2700, IBAN EUR - CZ3027000000001001885095 Tato zpráva má pouze informativní charakter, který vychází z podkladù, které byly odesílateli pøedány, nebo zaslány. Obsah této zprávy odesílatele nezavazuje, pokud to v ní není výslovnì uvedeno a odesílatel nemá v úmyslu na základì této zprávy uzavøít smlouvu, pøijmout nabídku, potvrdit uzavøení smlouvy ani nezakládá pøedsmluvní odpovìdnost jejího odesílatele, ledaže je odesílatelem ve zprávì uvedeno výslovnì jinak.Tato zpráva je urèena pouze pro osobní a dùvìrné užití osobou (osobami) uvedenou (uvedenými) výše. Nejste-li osobou, které je tato zpráva urèena, upozoròujeme Vás, že jakékoli šíøení, distribuce èi kopírování této zprávy je zakázáno. Jestliže tuto zprávu omylem obdržíte, prosíme, oznamte tuto skuteènost odesílateli a vymažte ji ze svého systému. The sole purpose of this message is to provide information based on materials that were given or sent to the sender. The content of the message does not place its sender under any obligation, unless expressly stated otherwise, and the sender has no intention to conclude a contract, accept an offer or confirm the conclusion of a contract on the basis of this message nor shall the message give rise to pre-contractual liability of the sender, unless it expressly states otherwise. The message is only intended for private, confidential use by a person (persons) mentioned above. If you are not the intended recipient of this message, you are hereby notified that any dissemination, distribution or copying thereof is prohibited. If you have received the message in error, please, inform the sender of the fact and delete it from your system.

2 1

Fwd: Registration Now Open - WG11 Midyear Meeting on Sept. 18-19, 2017 in San Diego
by John Wunderlich 12 Jul '17

12 Jul '17

For lawyers in the UMA legal group: https://thesedonaconference.org/node/108179? Two issues raised may be of interest to this group: - The latest draft of a commentary on reasonable or unreasonable data security measures - A brainstorming group outline on legal issues in cloud computing John Wunderlich, BA, MBA @PrivacyCDN <https://twitter.com/PrivacyCDN> *Privacy Tools* Kantara Initiative <https://kantarainitiative.org/>: Consent Receipt Specification <https://kantarainitiative.org/confluence/display/infosharing/Consent+Receip…> JLINC Labs <https://www.jlinclabs.com/>: Data Provenance Solutions <https://www.jlinclabs.com/solutions/> ---------- Forwarded message ---------- From: The Sedona Conference <info(a)sedonaconference.org> Date: 12 July 2017 at 09:34 Subject: Registration Now Open - WG11 Midyear Meeting on Sept. 18-19, 2017 in San Diego To: John Wunderlich <john(a)wunderlich.ca> [image: Logo] [image: Facebook] <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…> [image: Twitter] <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…> [image: LinkedIn] <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…> Working Group 11 on Data Security and Privacy Liability *Midyear Meeting 2017* Sept. 18-19 San Diego, CA When: September 18-19, 2017 Where: Rancho Bernardo Inn San Diego, CA Registration Fee: Regular Registration Fee: $1195 Government Employees: $895 Register Now <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…> Schedule of Events: - Meet-and-greet reception: 6:00 pm – September 17 - Start of Meeting: 8:45 am – September 18 - Reception: 5:15 pm – 7:15 pm - September 18 - End of meeting: 1:00 pm – September 19 MCLE: We are applying for MCLE credit. *REGISTRATION NOW OPEN* Register now for the 2017 Midyear Meeting of Working Group 11 at the Rancho Bernardo Inn in San Diego, California, on Monday-Tuesday, September 18-19, 2017. A welcome reception will be held on the evening of Sunday, September 17, from 6-8 pm. Please click here to visit the meeting webpage and to register <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…> . The meeting’s focus will be on new and updated work product in need of WG11 member review and comment, including: - Privilege in the data security litigation context - Law firm data security - Data security and privacy issues in civil litigation - Reasonable or unreasonable data security measures - Legal issues in cloud computing In addition, the meeting will again feature a data protection regulator roundtable. International developments in the field of data security and privacy issues will also be discussed, and the data security and privacy implications of emerging technologies such as artificial intelligence and Blockchain will be the focus of dialogue. Please check back in the next week or so for the complete agenda, and for names and biographies of confirmed dialogue leaders. Hotel Room Information We have obtained a very favorable room rate for WG11 members of $239 per night, plus tax. This favorable room rate is available for three nights preceding and three nights following the meeting, subject to standard guestroom availability. *Our room block expires on Thursday, August 25, 2017, so please register soon while rooms are available.* Complete hotel reservation details will be provided with your meeting registration confirmation. Membership *In order to attend the meeting you must be a member of WG11. If you are interested in attending the meeting but are not yet a member, you can become a member by signing up for a Working Group Series (WGS) membership <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…>.* Once a WGS member, one is eligible to take part in the activities of all Working Groups, including WG11. If you have any questions about how to sign up for a membership, register for the meeting, or encounter any difficulties while doing either, please contact Irina Goldberg at IGG(a)sedonaconference.org. Please join your fellow WG11 members at the 2017 Midyear Meeting in San Diego! ------------------------------ 301 East Bethany Home Road, Suite C-297, Phoenix, AZ 85012 Phone 602-258-4910 <(602)%20258-4910> Email info(a)sedonaconference.org ------------------------------ Copyright 2017 The Sedona Conference You are currently signed up to receive newsletters. To unsubscribe click here <https://thesedonaconference.org/index.php?q=civicrm/mailing/optout&reset=1&…> If you would like to resubscribe to receive emails from The Sedona Conference click resubscribe <e.4389.4148193.12910ccda163eff1@thesedonaconference.org?subject=I%20would%20like%20to%20resubscribe%20to%20TSC%20emails&I%20would%20like%20to%20resubscribe%20to%20TSC%20emails> -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

Re: [WG-UMA] Minor comment
by Justin Richer 12 Jul '17

12 Jul '17

This is a good point, might as well spell it out. --Justin Sent from my phone -------- Original message --------From: James Phillpotts <james.phillpotts(a)forgerock.com> Date: 7/11/17 3:57 AM (GMT-05:00) To: Eve Maler <eve(a)xmlgrrl.com> Cc: "wg-uma(a)kantarainitiative.org UMA" <wg-uma(a)kantarainitiative.org> Subject: Re: [WG-UMA] Minor comment Only in that in UMA 1.0 the token type hint was not access_token. J. On 11 July 2017 at 02:14, Eve Maler <eve(a)xmlgrrl.com> wrote: Since both PATs and RPTs are already formally defined, and function, as OAuth access tokens, I wonder if it's necessary to spell this requirement out. (The protection API is just about introspecting the RPT.) Eve Maler (sent from my iPad) | cell +1 425 345 6756 On Jul 10, 2017, at 6:44 AM, James Phillpotts <james.phillpotts(a)forgerock.com> wrote: Hi all, In https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.… given we just talk about RPTs and PATs, should we specify that the token_type_hint (if used) should be set to access_token? ref: https://tools.ietf.org/html/rfc7662#section-2.1 and https://tools.ietf.org/html/rfc7009#section-4.1.2.2 CheersJames _______________________________________________ WG-UMA mailing list WG-UMA(a)kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

2 1

Minor comment
by James Phillpotts 11 Jul '17

11 Jul '17

Hi all, In https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.… given we just talk about RPTs and PATs, should we specify that the token_type_hint (if used) should be set to access_token? ref: https://tools.ietf.org/html/rfc7662#section-2.1 and https://tools.ietf.org/html/rfc7009#section-4.1.2.2 Cheers James

2 2

Notes from UMA Legal telecon 2017-07-07 / a few extra notes and requests
by Eve Maler 07 Jul '17

07 Jul '17

A few more notes and requests: - There is *no Legal call next Friday*, as I've got a conflict. - Everyone please comment on the definitions <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/553hZKy8h…> *Tuesday, July 18*. Please send to the whole list. Ideally, don't just reply to this note; start a new thread with "Legal" in the subject. - *Tim,* if you're okay with it, let's please meet soon after that date to ensure you have what you need for deliverable #3. (I can also meet Mon-Thu next week.) - If anyone has any questions or thoughts, as always, please let me know. Thank you! http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-07-07 Attending: Eve, Kathleen, John, Ann, Mark, Tim Tim sent definitions according to the "exercise" Eve set. He derived many of them from UCITA, and some from prior UMA materials, including the draft model clauses, and then "protected resource" is new and may need more work. Let's treat these definitions, not as final model definitions, but our working draft that could be published in deliverable #3 (potentially accompanied by some diagrams showing mapping relationships) to show where the framework is headed. We can all review the document prior to the next call and send comments. *Access Contract:* *A contract or agreement to obtain by electronic means access to, or information from, an information processing system of another Person, or the equivalent of such access.* What is the difference between an access contract and an information sharing agreement? The former is a term out of UCITA law, so that's why he grabbed it. *Resource Owner:* *A Person with legal authority to grant access rights to Protected Resources; authorized to delegate access control functions to an ASO and to license access and use rights (permissions) relating to Protected Resources; acts as licensor to the Resource Server Operator.* Do both parts of the second clause relate to the ASO, or does licensing access and use rights pertain to the RO alone and not something the ASO mediates? The theory was that the ASO mediates this because it manages and executes/makes decisions on the RO's policies (which it does). Does taking out "*and*" in "*and to license access*" fix this, roughly? It seems so. Note: In UMA, the policy does not inherently travel with the resource, without some other layer of technology ("sticky policy" technology or similar). Do we need to define *Policy* (or *Authorization Policy*) vs *Business Policy* somehow? Does that add value to what we're doing? *Person:* *An Individual or Legal Person.* Great, same as before. *Legal Person:* *A legal entity means a corporation, business trust, estate, trust, partnership, limited liability company, association, joint venture, governmental subdivision, instrumentality, or agency, public corporation, or any other legal or commercial entity.* This seems to need just a touch of wordsmithing, e.g., "*A legal entity; a corporation...*". *Protected Resources:* *All data, applications, or software in which a Person either has Informational Rights or gives the Person the ability to exercise Informational Rights.* First, should this be singular? Second, regardless of singular or plural, the RSO has inherent authority in various aspects of "what counts as a resource" and "what types of access are possible to perform on a resource", as described here <https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.…> (so possibly it's worth breaking down into *Resource* and then *Protected Resource*, as the former is RS-related and the latter is AS-related?). Is it interesting to consider mentioning "URI" as the location of the resource somehow, or no? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: We have a Legal telecon tomorrow (Friday)
by Eve Maler 07 Jul '17

07 Jul '17

8am PT/11am ET/4pm UK/5pm CET http://join.me/findthomas Agenda: - Review a final proposal for UMA roles, their definitions, and licensing mappings and relationships, and other language to use/stick to in describing this world - Take a look at a visual formalism for explaining all this *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Notes from UMA Legal subgroup telecon 2017-06-30
by Eve Maler 01 Jul '17

01 Jul '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-06-30 Attending: Eve, Tim, Kathleen, John W, Bjorn, Colin, Mark L, Sal, Mary Let's clarify all our role terms and concepts today: 1. *Resource Owner** (was Grantor)* 1. *Data Subject* *(was Resource Subject)* (has privacy framework meaning) - could be the Resource Owner or has delegated authority to a separate Resource Owner by law or contract 2. *Authorization Server Operator* - Agent (fiduciary?) of the Resource Owner - role is controlled by the PAT, and in practice it issues the end-to-end licenses because it issues the RPTs 3. *Resource Server Operator* - Data Controller (has privacy framework meaning) - is the Resource Server Operator 4. *Client Operator* - 1st-tier Data Processor (has privacy framework meaning) - is always the Client Operator? or if the Resource Owner grants access in order to make the Requesting Party be another Data Controller, what does that make the Client Operator in this case? 5. *Requesting Party* - 2nd-tier Data Processor (has privacy framework meaning) - is always the Requesting Party? - or maybe the Resource Owner wants to make the Requesting Party be another Data Controller? 1. *Access Beneficiary*??? - a party that the Requesting Party is acting on behalf of, either themselves or another party - a better name for this? We definitely don't like the word "ownership" of data or records. Is there licensing of data, or a record, or what? Since the access grant could be about disclosure of data, or deletion of data, or execution of an algorithm, or whatever, the licensing similarly could be sophisticated. It could specify that the recipient gets a copy of the data, etc. We want to have a concordance between all of these roles and the UMA flow. Do we use the role terms *Licensor* and *Licensee* at different points in our clause text vs. the terms above? Or can we punt on that for now? E.g., maybe the Resource Owner becomes (dons a role of) a Licensor at a certain point in a contract, and a Requesting Party becomes a Licensee. Two of the parties listed above would be parties to the license/contract, and others are subsidiary. But we still need to complete our mapping work to understand the precise relationships of them all, wrt UMA. The Resource Owner is the one that has to hire/contract with the ASO, because it can't be someone who doesn't have legal capacity etc. Or even if the Data Subject contracted with some agent, say, an attorney, to take care of financial business or whatever for them, then that Resource Owner really does function as their delegated agent and contracts with the ASO on their behalf. Of course, just as in Google Docs, the agent might need to "transfer ownership" of resources back to the data subject at some point – and the IRM group's design guidelines include just such actions! Delegable, Transferable, etc. This justifies our "indenting" the Data Subject role; it's "offline" wrt UMA, and our model. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0