February 2016 - WG-UMA - mailman.kantarainitiative.org

Notes from UMA legal telecon 2016-02-19
by Eve Maler 22 Feb '16

22 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-02-19 - *Distinguishing resource subjects from resource owners:* Can we develop a cohesive system whereby "resource subjects" without legal capacity can have "authorized agents" acting on their behalf as "resource owners" as required in order to forge "resource registration agreements" for the purpose of UMA's phase 1 particulars? Do the use cases/design patterns provide any insights or challenges here? - See email thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/pn5KRXJt2…> Attending: Eve, Andrew Hughes, Paul L, John, Ann, Adrian, Jon, Kathleen, Sal Is it valuable to solve for a model where an agent can be working on behalf of resource owner vs. a resource owner? The protean nature of the word "agent/agency" is troubling. Is there a good substitute word? If not, do we have to define *Agent for all of our terms in an UMA context? We did already have Requesting Party Agent. Perhaps, at best, we should define it operationally but stay away from legal subtleties. We've said that resource owner = Authorizing Party. Does that work, or is it not equivalent? There are terminology questions and there are UMA architecture questions. Should we just wave away problems by making them equivalent? - *1yo case:* What if the "resource owner" (let's say they're the "subject" of the data residing in the RS) is a one-year-old kid and their mom has to manage the resources by logging in to the RS? The child is not competent to contract, even if they're old enough to sign their name. *Guardian* is a good name for the latter. - *12yo case:* What if the "resource owner" (let's say they're the "subject" of the data residing in the RS) is a 12-year-old kid and they're old enough to manage the resources by logging in to the RS themselves? The child is not competent to contract, even if they're old enough to manage resources online. How to architect the system and name the parties? - *Intermittently competent adult case:* This is another tough one. - *Competent adult case:* What if the "resource owner" (let's say again that they're the "subject" of the data residing in the RS) is actually competent to contract, but wants to have someone else manage resources for them online? There's a paper resource owner, but an online "executor" of resource management. What's a good term? - *Digital death case:* After the "resource owner"... Adrian's concern is what happens in phase 1. These use cases have different properties in that phase. Eventually (soon), we will be in a position to work on what's supposed to happen when RS's want to take an action in response to an access request that is in contradiction to the permissions contained in an RPT (requesting party token). First, we need to understand exactly "who" configured the AS to By the way, all the same patterns could apply whether or not the resources contain PII or not. What if the resource owner created digital media that they want to sell? Is there a reason to distinguish in our terminology at all? What if a resource contains PII "in bulk" for many individuals (in directories or databases or other repositories)? This was the point of Adrian's example. Eve's point was, rather, that individuals might want to be protecting resources that don't contain PII. Okay, now we're on the same page! There are use cases for UMA that span "Alice" and "enterprise". Let's try to conclude this decision-making process by next week, and then move on to the decisions about RS actions in contradiction. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

8 25

Draft minutes of UMA telecon 2016-02-18
by Eve Maler 20 Feb '16

20 Feb '16

Great meeting, all! http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 MinutesRoll call Quorum was reached. Approve minutes Minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> approved. Issue #239 - *Proposal:* Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already) Proposal accepted. - *Proposal:* Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension Sal and Eve just discussed in email whether a stronger authentication mitigation would work. Session fixation happens after victim authentication, so it wouldn't help. Robert mentioned to Eve offline that Wikipedia has some comments on session fixation that might be useful. Eve believes that since the permission ticket gets passed in UMA JSON messages, the countermeasures there may not apply, but we could look (for purposes of the non-normative analysis if ultimately nothing else). - *For discussion:* Consider also handling issue #167 in this extension if it has a security rationale If the AS uses the flexibility to give a new endpoint, then there's the danger of giving an attacker new information outside of the discovery document that it didn't have before, which is a degradation of security. If the AS doesn't avail itself of the flexibility, then it doesn't seem to add anything. In any case, we're not thinking of a security rationale for adding this feature to the extension. In any case, it sounds like taking up #167 as part of the extension work doesn't meet our "#security use case bucket" goals, so we'll defer that till such time as we take up "#simplify use case bucket" work. *Consensus:* We want to write and publish the extension specification. - *For discussion* (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG - *For discussion* (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue) The WG itself can self-approve a technical specification, and the LC can approve that group output. (Are these "WG Reports"? Eve will check with the LC.) In other words, this could remain at a level sort of equivalent to an IETF I-D and not progress to an "RFC" level before it eventually gets absorbed into a later version of the UMA Core spec. We do want to recommend that everyone using the claims-gathering endpoint use this approach, but it all depends on the timing of any new UMA "V.next" version. We basically need to defer the decision about its "track" until we execute on the rest of our roadmap. *AI:* Eve, Domenico, Maciej: Write the extension spec. Can we publish these by next Thursday? Let's give the old college try. We want to publish and publicize the draft docs at the same time. Wide ecosystem challenges Eve presented a set of high-level statements that describe the dual nature of the challenges. Eve/James and Maciej will share some material on the challenges. John observes that it's an ouroboros – a snake eating its own tail (or as Eve likes to call it, the bubble under the wallpaper that you can move but you can't remove). Some discussion arose about different solutions, e.g.: - UMA-protected user claims endpoint ("UserInfo") - Agreed-on central authority (e.g. hospital) serving as a claims endpoint/AS (?) – akin to the question that has arisen over the last decade-plus about "who's the IdP" The group agreed to collect all the potential solutions "without fear or favor" and then analyzes how well they solve the challenges. Attendees As of 16 Feb 2016, quorum is 6 of 10. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike) 1. Eve 2. Kathleen 3. François 4. Domenico 5. Sal 6. Mike 7. Maciej Non-voting participants: - John W - Sarah - Adrian - George - Scott - Mark - *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 10

Human-readable summary of Issue 239 and the current proposed solution
by Sarah Squire 20 Feb '16

20 Feb '16

Hi all, I took an action item last week to summarize issue 239 in a human readable format. Here it is: Alice wants to share a photo with Bob, and only Bob. Eve would like to see the photo, but she is not allowed. Alice stores the photo on her resource server and protects it with her authorization server. She sets a policy stating that only Bob should have access to the photo. In order to get Bob access to the photo, three steps are completed: 1. Bob begins his transaction by requesting the photo 2. Bob identifies himself within the context of his transaction 3. The authorization server grants access to the photo within the context of his transaction Eve would like to access the photo as well. She completes the following steps: 1. Eve begins the transaction by requesting the photo 2. Rather than identifying herself, Eve phishes Bob and convinces him to identify himself within the context of her transaction 3. The authorization server grants access to the photo within the context of her transaction Because Eve’s attack involves a successful phishing event, this scenario is not considered a vulnerability in the classic sense. The attacker must know the victim and successfully trick him. As such, the UMA working group is proposing that no normative changes be made to the core specification at this time. We propose a security enhancement extension to be used optionally in contexts where a higher level of security is appropriate. The extension we propose would disallow access to Eve by making each step in the process a different transaction so that when Bob identifies himself, it then becomes his transaction and Eve has no way to recover the context in which access was granted. We feel that this is an elegant solution that is easy to implement and in fact makes the software Bob has to use (also known as the Client) simpler than it would otherwise be since it no longer has to remember the transaction context from beginning to end. Sarah Squire Engage Identity http://engageidentity.com

3 2

Human-readable summary of Issue 239 and the current proposed solution
by Sarah Squire 19 Feb '16

19 Feb '16

Hi all, I took an action item last week to summarize issue 239 in a human readable format. I've included it below. It sounds like there is also a need for a general analysis of the proposed solution and why we chose it. I can write that up too. For now, here's a very high-level description of what's going on: Alice wants to share a photo with Bob, and only Bob. Eve would like to see the photo, but she is not allowed. Alice stores the photo on her resource server and protects it with her authorization server. She sets a policy stating that only Bob should have access to the photo. In order to get Bob access to the photo, three steps are completed: 1. Bob begins his transaction by requesting the photo 2. Bob identifies himself within the context of his transaction 3. The authorization server grants access to the photo within the context of his transaction Eve would like to access the photo as well. She completes the following steps: 1. Eve begins the transaction by requesting the photo 2. Rather than identifying herself, Eve phishes Bob and convinces him to identify himself within the context of her transaction 3. The authorization server grants access to the photo within the context of her transaction Because Eve’s attack involves a successful phishing event, this scenario is not considered a vulnerability in the classic sense. The attacker must know the victim and successfully trick him. As such, the UMA working group is proposing that no normative changes be made to the core specification at this time. We propose a security enhancement extension to be used optionally in contexts where a higher level of security is appropriate. The extension we propose would disallow access to Eve by making each step in the process a different transaction so that when Bob identifies himself, it then becomes his transaction and Eve has no way to recover the context in which access was granted. We feel that this is an elegant solution that is easy to implement and in fact makes the software Bob has to use (also known as the Client) simpler than it would otherwise be since it no longer has to remember the transaction context from beginning to end. Sarah Squire Engage Identity http://engageidentity.com

1 0

Agenda for UMA legal telecon 2016-02-19
by Eve Maler 19 Feb '16

19 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes Date and Time - *Fridays,* 8-9am PT - Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:**IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar 2016-02-19 - *Distinguishing resource subjects from resource owners:* Can we develop a cohesive system whereby "resource subjects" without legal capacity can have "authorized agents" acting on their behalf as "resource owners" as required in order to forge "resource registration agreements" for the purpose of UMA's phase 1 particulars? Do the use cases/design patterns provide any insights or challenges here? - See email thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/pn5KRXJt2…> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

[legal] GDPR action plan under way, meaning GDPR interpretation
by Eve Maler 17 Feb '16

17 Feb '16

https://iapp.org/news/a/article-29-working-party-lays-out-gdpr-action-plan/ *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

Agenda for UMA telecon 2016-02-18
by Eve Maler 17 Feb '16

17 Feb '16

Lots of interesting stuff to discuss and decide tomorrow. Please try and join. http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18 Date and Time - *Thu Feb 18,* 9-10am PT - Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> - Review the recommendations for issue #239 and decide and execute on next actions - Proposal: Regardless of other decisions, develop a non-normative analysis of the attack and mitigations; revise as appropriate depending on other decisions taken (Sarah has this AI already) - Proposal: Develop an extension specification, Enhanced Claims-Gathering Security Extension, to require cycling of the permission ticket when using the claims-gathering extension - For discussion: Consider also handling issue #167 in this extension if it has a security rationale - For discussion (thanks Andi for these two new bullets!): Consider updating the UMA Core spec in some way to point non-normatively to the extension spec, and/or mention it from the UIG - For discussion (possibly at a later juncture): Consider if/when/how to fold the extension into a future UMA version (likely to be captured as a GitHub issue) - For meta-discussion: What to do right now, as soon as we decide all this? - Kicking off #wideeco discussion: inputs from Eve/James and others - Making plans for IIW - Thoughts on tasks we can accomplish there: CIS-flavored, legal-flavored, and interop-flavored efforts? - Who will definitely be there? Whose plans are contingent on the WG's plans? - Charter-bashing <https://docs.google.com/document/d/1cv7MLdpC1SMubREbZX7L8E4YUPCAzKPwOCFBky6…> (thanks Adrian for kicking this off!) - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

AI: Adrian: Write up ROI form concerns wrt to UMA phase 1 implications for the group's consideration. [Legal]
by Adrian Gropper 16 Feb '16

16 Feb '16

- Definitions: *Resource Registration Agreement* - A contract between the Resource Server Operator and the resource subject or authorized agent of the resource subject that defines a resource pertaining to the resource subject, including available and supported scopes, and delegates some control over that resource to an Authorization Server. The Resource Registration Agreement establishes Phase 1 of the UMA Protocol at a time when neither the Client nor the Requesting Party are known to either the RS / RSO or the AS / ASO. As such, this is equivalent to a typical healthcare ROI form if the ROI form were to *specify an agent for the subject instead of the client* for for the purpose of authorized access to the resource. *Authorization Server Endpoint* - The URI and associated .well_known endpoints of a standards-based authorization server acting as the agent of the resource subject during UMA Phase 2. Under this Resource Registration Agreement, the RSO agrees to consider a token signed by the AS as presented by the RqP / Client. The RS may either accept the token or it can notify the AS that the token was not accepted or modified in scope. *Resource Subject Signature and Date* - The individual who's PII is accessed via the resource. This individual could be any age and should not need to be able to read or write or use technology. *Authorized Agent Name, Signature and Date* - The individual that the RSO recognizes as an authorized agent of the resource subject in cases where the resource subject is unable to sign for herself. The basis of this recognition is completely out of band from UMA. - Is this UMA? In my subject-centered vision of UMA, the RS has no visibility into whether the Resource Subject or the Authorized Agent or anyone else is in control of the Authorization Server Endpoint. In Phase 2 or 3 of UMA, the RS can choose to take attributes of the Client and RqP into consideration along with the Token issues by the AS or the RS can accept the token as is. If the RS changes the intent of the token, either more or fewer privileges, then the RS must notify the AS of the change. It may be that my subject-centered vision of UMA is not actually UMA. I don't know. If it's not, then we should try to give it a name because all I'm talking about is the subject's right to specify an agent by executing a Resource Registration Agreement - period. Adrian -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

3 4

Notes from UMA telecon 2016-02-11
by Eve Maler 16 Feb '16

16 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-11 MinutesRoll call Quorum was not reached. Approve minutes Deferred. OTTO WG OTTO stands for "Open Trust Taxonomy for OAuth2". This proposal <http://ox.gluu.org/doku.php?id=otto:proposal> captures the work that is now rapidly progressing. It's a generic way for defining a registry of services, no matter what metadata might be used for the services (SAML, OAuth, other). Are any other "trust bundle" sources using dynamic methods of updating? A number of federations in the education space are straining to scale. The OTTO proposal uses json-ld, which has some interesting properties, such as canonicalization and XML Signature-like signing. Justin notes that the JOSE group explicitly avoided canonicalization because it comes with so many pitfalls. The proposal includes some UMA RS-to-AS onboarding examples. Mike is calling for people to participating in the WG <http://kantarainitiative.org/confluence/display/OTTO/Home>, which meets on Wednesdays 8am PT/10am CT/11am ET/4pm UK/5pm CET. What about other systems, such as NIEF and GTRI? Are they actually comparable in terms of functionality? Unclear. Adrian mentions some past work with similar efforts that had some disappointing and privacy-invasive results. Consent receipts and UMA There's interest in the "shoebox endpoint" in the context of UMA. Sarah speaks in favor; she's been working on the id-events space of late. John mentions a shoebox is a kind of KeyPass or 1Password or similar user space solution. A clearly defined technical specification for consent receipts enables organizations with customer obligations around consent management to build their own tools appropriately. Adrian speaks in favor of the shoebox endpoint, but philosophically he sees it as a *notice* endpoint, not necessarily (just?) a repository of *consent*. This is related to agency law; you can't have a viable business structure around UMA unless you have a notice capability. Adrian: "At some point we are going to have to do privacy engineering around UMA." – this is not really separable from the #wideeco use case, in the sense of blinding/credential brokerage/privacy-preserving identity mechanisms. Regarding "notice and consent", John notes that the consent receipt reflects the result of a transaction. In different jurisdictions (US vs. EU), privacy is contractual vs. human rights-based. Prioritization For the whole WG (for now): 1. #security 2. #wideeco 3. #shoebox (the technical side) 4. #IoT For the legal subgroup (for now): 1. #trust generally (which is just developing model clauses etc.) 2. #RSctrl and #ROctrl and #shoebox (the legal side) Charter *AI:* Adrian: Take a look at the current UMA WG charter and recommend any wording changes. Andi to help as he sees fit. Issue #239 discussion and review Eve presented the attack and the proposal briefly. The threat is applicable only to some methods of trust elevation (not to step-up authentication, nor to pushed claims, only to interactively gathered claims at the claims-gathering endpoint), and is not applicable to any known or imminently planned UMA deployments (e.g., Gluu's current deployments use step-up authentication only). The subgroup looked at quite a few potential mitigations and rejected most. The one it recommends for now involves adding entropy to the permission ticket so that an attacker RqP can't steal away a victim RqP's already trust-elevated right to access an RO's protected resource. Any mitigation would be backwards-incompatible. We have recommended packaging the proposed mitigation in an extension spec so that only those needing it can deploy it alongside core UMA in an identifiable way. When the time is right, we can choose to slot it into core UMA, or by then, we might have designed a wholly new UMA V.next design. Mike, Kathleen, and Adrian speak in support. Andi has some concerns that he will send in email. Mike suggests, if we go this route, putting an erratum note of some kind in the base spec. Kathleen notes that getting a mitigation out sooner is better because otherwise people just assume protocols like UMA are safe and there could be a backlash. Would incorporating the proposed mitigation into the core spec mean we'd make a V1.1 or something? Nominally no, because we have adopted semantic versioning. *AI:* Sarah: Draft a "friendly doc" describing the exploit and the proposed mitigation(s). *AI:* Eve: Send Sarah the source WSD for the attack. Let's try and get a full set of voting participants to attend soon so we can have a full discussion and decision. Attendees As of 20 Jan 2016, quorum is 7 of 12. (Evariste, François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike) 1. Eve 2. Kathleen 3. Mike 4. Maciej 5. Andi 6. Domenico Non-voting participants: - Sarah - Justin - John W - Adrian - George - James - Ishan - Jin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Proto IoT Use Case - Replacing the condo front door key-fob
by Adrian Gropper 15 Feb '16

15 Feb '16

Here's a use-case to consider for UMA and IoT: Replacing the condo front door key-fob by assuming everyone who might need a fob has a smartphone. Most condos use a key-fob to secure doors that don't have a doorman. The gray fob on your keychain is expensive and inconvenient when it needs to be passed around to guests or causes phone calls to neighbors when an authorized visitor does not have the fob. Now assume that a smartphone as UMA Client replaces the fobs and that the door lock is connected to the Internet as an UMA Resource Server controlled by the condo management as RSO. This use-case highlights at least two issues around UMA and IoT. First, it seems unreasonable to consider this a narrow or medium ecosystem use-case. The condo apartment owner would not be pleased to have as many UMA Authorization Servers to deal with as she has situations of controlled access to a shared resource. Second, the nature of the UMA solution may need to be sensitive to proximity and redundancy so that a RqP with a (wireless) LAN connection can access the lock even if the WAN is inaccessible. Where is the condo apartment owner's AS located? Isn't it in the apartment with both LAN and WAN connections? This works for Thing resources within radio range but could benefit from a synchronization mechanism that allows the RO's AS to be more or less replicated in the cloud. Adrian -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

1 1