- WG-UMA - mailman.kantarainitiative.org

Reminder: Legal telecon tomorrow
by Eve Maler 03 Aug '17

03 Aug '17

http://join.me/findthomas 8am PT/11am ET http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes https://docs.google.com/a/meshfire.com/presentation/d/1I12agEsfaJK3LEiJyROr… *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-08-03
by Eve Maler 03 Aug '17

03 Aug '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-03 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>, UMA telecon 2017-07-27 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-27>: APPROVE by acclamation. Schedule for upcoming weeks Eve can't make the Aug 10 meeting. Andi is away next week and the third week out. Domenico is out starting Aug 14. If we had an e-ballot running during the last week of August to approve the specs for a new Public Comment period, voting participants on the call could be available online the week of Aug 28 and the week of Sep 4 (that day itself is US Labor Day). AI: Eve: Send invitation for Monday Aug 7 at 9am PT as a substitute for Thursday Aug 10. Eve should be available at our normal times for the following three weeks; we'll see if we can continue to get critical mass then (if not official quorum). UMA 2.0 work #337b <https://github.com/KantaraInitiative/wg-uma/issues/337>: This harks back to Pedro's comments and Justin's responses about the grant's "agnosticism" to clients. The assumption wording in Grant Sec 3.3 now is: "The client has obtained OAuth client credentials from the authorization server, either dynamically through [RFC7591] or [OIDCDynClientReg], or alternatively through a static process, and is prepared to authenticate itself to the token endpoint if appropriate." Instead we could say: "The client has obtained a client ID or a full set of client credentials as appropriate, either statically or dynamically (for example, through [RFC7591] or [OIDCDynClientReg]). This grant works with clients of both confidential and public types." *We have consensus.* #339 <https://github.com/KantaraInitiative/wg-uma/issues/339>: James misinterpreted the wording in FedAuthz Sec 4.1 and so suggested that the RS should get flexibility: object *or* array at its discretion for a single permission in the request, with the AS picking up the slack. The spec would have to clarify/change the wording and probably add an example of the single-object-in-an-array way of doing things. Reactions: - Removing the object option would have been breaking. This isn't. - Typically, adding "two ways of doing things" would be unattractive (except for backwards compatibility reasons; we did that in V1.0.1 and then, in some cases, removed the old deprecated methods in V2.0). - Any insights from OIDC history? Spec design philosophy has been to make the AS do the heavy lifting – we have exactly the same. #341 <https://github.com/KantaraInitiative/wg-uma/issues/341>: Eve's suggestion in the issue thread was that there are two use cases: synchronous and asynchronous. But what does that mean? She meant that by the time the RO responds, it would be impossible to consider their response during the RqP's session. But the discussion from issue #298 <https://github.com/KantaraInitiative/wg-uma/issues/298> is about how it's not a matter of time elapsed, but use cases where the RO's policy says "ask me every time", such that *not* issuing a ticket at all means that the AS would have "amnesia" when the client returns even after a very lengthy period of time. If it returns directly to the AS with the ticket after, say, several days, ticket in tow, even if all the other necessary claims have expired etc., there might then be a record of the RO having said "yes" and claims-gathering could proceed as required. If we decide to change from MUST return a ticket to MAY, then all the client can do when the AS doesn't return a ticket is obviously to start over at the RS. It turns into a terminal type of error from a continuance type of error. Ultimately, a MUST forces it to be one kind of error, while a MAY lets the error function for two different kinds of use cases. So we have two clear options (probably still adding that the AS should document its type of request submissions regardless?): - Option 1: Keep the MUST, which is a terminal error. - Option 2: Change to MAY, which splits into terminal and continuance errors. 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. Cigdem Non-voting participants: - Kathleen - Bjorn Regrets: - James *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-08-03
by Eve Maler 02 Aug '17

02 Aug '17

*(Please review new/existing open issues and weigh in before the call!)* http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-03 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 telecon 2017-07-27 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-27> - Schedule for upcoming weeks - *Can't meet Aug 10*; substitute another time? - When are people on vacation? - 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 <http://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html> /FedAuthz rev 06 <http://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.h…> - We need to work through the open issues, so please weigh in on GitHub if you have opinions - Candidate motion when we're ready: "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 (defer till we're in All-Member Ballot) - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

For UMA legal. How would the licensing on this resource work?
by John Wunderlich 01 Aug '17

01 Aug '17

Judge: Lawyers may need to justify $1.12M fee request for '3 months work' in sex toy case settlement | Cook County Record Source: http://cookcountyrecord.com/stories/511162880-judge-concerns-over-1-12m-law… (via Mr. Reader) Thanks, John Wunderlich @PrivacyCDN Pleez 4give speling errurs, sent from a mobile device. -- 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

Exemplary real world use case for UMA
by John Wunderlich 01 Aug '17

01 Aug '17

The advocates in the linked article make a good case why the health records of children with congenital health issues that now survive much longer should be kept for life. But this puts burden on the health information custodians with respect to staying in touch with the adult, respecting their consent directives, and respecting regulatory requirements. How much better would be a patient managed/controlled/owned resource server...? https://www.thestar.com/news/queenspark/2017/07/28/medical-records-of-sick-… -- 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.

3 4

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