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

Thoughts on resource set scope "math"
by George Fletcher 06 Nov '16

06 Nov '16

Assumptions: 1. In UMA, scopes are really "per user" rather than per API. Now it is unlikely, and not encouraged, that an RS would produce an API where the scopes are really unique to each user. In most cases it is more likely that the RS will have a set of defined scopes that work across their entire API and hence across all registered resources. 2. For any given resource set, a subset of the full list of the scopes supported by the RS may be registered. Sets of scopes as identified in the meeting notes from 2016-06-02 [1] 1. The universe of scopes the RS has registered for the resource set 2. The scopes the client has registered for at the AS (if it has done this at all) 1. Note that I would add to this that this list of scopes should rather be the list of scopes the AS has determined the client is allowed to request 3. What the RO has attached to the policy for the resource set 4. What the RS requests for at the permission endpoint (in order to get a ticket) 5. The scopes the client requests at the token endpoint Possible algorithm for determining the set of scopes to be issued with a permissions ticket. * The max possible set of scopes that could be returned from the /token endpoint when requesting a token is the "universe of scopes the RS has registered for the resource set" identified by the permissions-ticket * The allowed set of scopes that can be issued by the UMA AS is the INTERSECTION of "universe of scopes [#1]" and the scopes allowed by the RO policy for that resource set [#3]. Let's give this resulting set a number of [#6] {allowed scopes for the resource set} * The list of scopes requested by the client is determined by the INTERSECTION of [#2] and [#5]. Let's give this resulting set a number of [#7] {scopes the client is allowed to request} * The set of requested scopes is the UNION of set [#7] and set [#4]. Let's give this resulting set a number of [#8]. * The max scopes that can be allowed for this access_token request is the INTERSECTION of set [#6] and set [#8]. Mapping this to pseudo-code: Set PossibleScopes = RegisteredResourceSetScopes INTERSECTION ROAllowedScopes Set ClientScopes = ASAllowedClientScopes INTERSECTION ClientRequestedScopes Set RequestedScopes = ClientScopes UNION PermissionTicketScopes Set AllowedScopes = PossibleScopes UNION RequestedScopes Thanks, George [1] https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02

5 6

Gaps in Oversight of Privacy and Security of mHealth Technologies and Health Social Media
by John Wunderlich 30 Jul '16

30 Jul '16

The predecessor and marketing problem before UMA or CISWG is how to get entities that aren't required to give users control over their own data to do so. https://www.healthit.gov/sites/default/files/non-covered_entities_report_ju… Thanks, John 4giv spellin errurz from mobile devize -- 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 2

Notes from UMA legal telecon 2016-07-28
by Eve Maler 29 Jul '16

29 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-07-28 - Review User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> Attending: Eve, Scott, Adrian, Jeff S, Jeffrey R, John, Kathleen, Jim The 50K-foot view: We are tardy on our original model definitions and clauses schedule, but our "primer" deliverable is intended (ultimately) to drive clarity and force around the model text deliverable. Do we want to enlarge our scope to encompass "enterprise UMA"/federated authorization use cases? Maybe we give it a nod, but don't address it fully. We may want a separate, similar paper on the "Legal Person" opportunities. Our history with BLT in the primer: It didn't survive our analysis of doc structure. Scott's history with the invention of BLT: It was meant to be extractive: breakdown and then buildup. It might be the case that the duties within our obligations in the model clauses have "BLT metadata" somehow, if it's determined that this is useful, but they seem not to be a useful organizing principle in the doc. In the intro, we want to get from a sharp Problem to a Solution and then to an enticing How we're going to help them solve it. UMA can help soft, fuzzy circumstances become harder and more measurable. What scenario should we pick? Should it have "health" in it? We always debate this. Should we go with "smart home" and non-health, perhaps? Or "pure Google Apps-like"? We could tweak it to have smart home for a disabled person to allow them to live at home vs. other circumstances. That introduces an additional layer of regulations, however. The appeal of health is that the data is so intimate and sensitive. A baby monitor, or some other smart home devices, might have the same characteristics, though. IoT seems definitely popular. Homework for next time: Please send your own ideal 1-2 paragraph scenario to the list so we can nail this down next week and power through the next section. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA legal telecon 2016-07-28
by Eve Maler 29 Jul '16

29 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… Date and Time - *Fridays,* 8-9am PT - Voice: Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web interface <https://panel.turbobridge.com/webcall/>, code 178-2540# - Screen sharing: http://join.me/findthomas – NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar 2016-07-28 - Review User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-07-28
by Eve Maler 28 Jul '16

28 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-28 Agenda - Roll call - Approve minutes of UMA telecon 2016-06-30 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-30> , 2016-07-07 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-07> - For reference: MPD sequence diagram <http://www.websequencediagrams.com/files/render?link=2DdzslbnVj3ShhlrLVV-> and generic low-level sequence diagram <http://www.websequencediagrams.com/files/render?link=V0tZE2kWrO0l-tGlZX1a> - Including multiple resource sets while registering for a permission ticket - Review Justin's proposal (if available) on success and error responses in case of attempts at registering multiple resource sets (general idea: Boolean, single ticket) - What is necessary to do in UMA about RSR for standard APIs? - Thread with Adrian - Begin building a comprehensive model for client awareness of scopes and set math <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> at every step - AOB MinutesRoll call Quorum was not reached. AI: Eve: Clean up the rolls. Approve minutes Approve minutes of UMA telecon 2016-06-30 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-30> , 2016-07-07 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-07>: deferred. Multiple resource sets in permission registration Nothing much to say beyond last week's discussion. Let's just parcel out the spec text assignment. UMA specs wrt standardized APIs with standardized resource and scope semantics What should an UMA AS as a value-add standardized API server do? E.g., since the FHIR API has a really huge structure for "resources" (UMA resource sets) with a hierarchical structure, Adrian suggests that when a requesting party's client shows up and attempts to access some 'higher-level" or "containing" resource, the resource owner needs to be able to instruct the AS to give access to some subset of the resources "within" or "associated with" it, and not all of them. On the Release of Information (ROI) form that US hospitals have patients fill out, there's a place where patients can initial that HIV information would specially be permissioned to be shared vs. not. (Is that right?) The word "itemization" might capture the issue. If there's a special "FHIR AS" and "FHIR RS" vs. the plain ones, they wouldn't have to use the regular RSR interface to exchange information by brute force about the resource sets and scopes; it could be done implicitly based on a separate profile or something. It seems out of scope for UMA to standardize, because anyone can invent a standard API with sectoral or whatever semantics, and UMA protects that API. A URI could be pointed to that represents those semantics. The protection API extensibility profile <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#alt-prot-pr…> in UMA could be an excellent tool for enabling "implicit RSR" of these well-known FHIR semantics. Adrian is concerned that an RS that doesn't know about FHIR doesn't fail, however; thinking about graceful degradation is a good idea. If the profile is listed in the AS's discovery document (the "configuration data"), that would enable the RS to know what the AS is capable of supporting. Should we have a way of letting the AS declare hard requirements to RS's? Any one RS knows whether it supports whatever profile or not; Adrian wants there to be a way, in the case of naive AS's, for the RS to adhere to the web mantra of being strict in what it produces and generous in what it accepts. Sal points out IoT devices with APIs could have their own profiles, and so on ("physical resources such as doors, e.g. access to public space, access to employee space, access to restricted by role space and super secret (e.g. a SCIF)"). We have *consensus* on this direction. Editorial instructions: - Write up the solution for the UIG: - This is an example of how a third party (e.g., the HEART WG) would leverage the protection API extensibility profile to create an out-of-UMA-band mechanism for the standardization of resource set types and their associated scopes. - It would involve the use of the protection API extensibility profile. - It would involve the definition of an extension profile because the API is standardized (meaning it is independently implemented by multiple implementers). These definitions would, we believe, involve implicit usage of the "type" field. - It would involve implicit registration of resource sets and their scopes, not explicit use of the RSR API endpoint, for at least some resource sets (would there be explicit RSR for a "bootstrap" resource set?). - Extensions and profiles are already recommended to contain security and privacy considerations sections. - We should recommend that HEART be our guinea pig and write tiny profiles for these and then implement them to see how it goes. Editorial instructions for spec text work: - Create updated swim lane contemporaneously Client awareness of scopes and set math We'll start with these notes <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> next time. Attendees As of 28 Jul 2016 (pre-meeting), quorum is 7 of 13. (Domenico, Kathleen, Sal, Nagesh, Andi, Robert, Paul, Agus, Maciej, Eve, Jeffrey, Mike, Sarah) 1. Domenico 2. Sal 3. Eve 4. Jeffrey Ritter <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/zyyROUnKT…> – lives in Durham, NC – tech standards from the legal end – UN electronic commerce, information security, ISSA, more recently Oxford and Johns Hopkins – coined/invented "quantum law" 5. Mike 6. Sarah Non-voting participants: - Adrian - James - François - Colin - Scott S - John - Jin - George Regrets: - Justin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Self-Introduction of New Group Member Jeffrey Ritter
by jeffrey＠jeffreyritter.com 28 Jul '16

28 Jul '16

Hi all: At Eve Maler's suggestion, I am writing this note to introduce myself. I am currently a Visiting Fellow at Kellogg College, University of Oxford, resident in the Department of Computer Science where I have the good fortune to conduct research and publish on the topic of quantum law (a term of my own creation). In fact, I am joining the group as a result of my initial public lecture on the first principles of quantum law in early May, 2016. That lecture provoked someone to identify your work and make an introduction. I also teach Information Security Policy Development and Privacy Engineering at Johns Hopkins University, Whiting School of Engineering in their cybersecurity track, and have previously taught at Georgetown University Law Center. I have had a long and intensive engagement with standards development for digital commerce, information security, and implementing next generation technologies. Across the legal and technology chapters of my career, I hope I have gained an understanding of how to make great standards; the work of UMA is important and I encourage anyone to reach out and see if I can be useful to your momentum. For the rest of the introduction, you can just google me or visit [ www.jeffreyritter.com ]( http://www.jeffreyritter.com ). I look forward to working with all of you. Best regards, Jeffrey Jeffrey Ritter Visiting Fellow at Kellogg College, Oxford University [ www.jeffreyritter.com ]( http://www.jeffreyritter.com/ ) 202.285.7385 @Jeffrey_Ritter [ Achieving Digital Trust ]( http://www.amazon.com/dp/0996599002 ) is now available on Amazon. "I don't know why Jeffrey came back from the future to teach us how to adapt to what's coming, but he did, and I am grateful. Thank you Jeffrey." --Peter E. Sand, Executive Director of Privacy,MGM Resorts International

1 0

Agenda for UMA telecon 2016-07-28
by Eve Maler 27 Jul '16

27 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-28 Date and Time - *Thursdays,* 9-10am PT - Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web calling interface <https://panel.turbobridge.com/webcall/> / code 1782540 - Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-06-30 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-30> , 2016-07-07 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-07> - For reference: MPD sequence diagram <http://www.websequencediagrams.com/files/render?link=2DdzslbnVj3ShhlrLVV-> and generic low-level sequence diagram <http://www.websequencediagrams.com/files/render?link=V0tZE2kWrO0l-tGlZX1a> - Including multiple resource sets while registering for a permission ticket - Review Justin's proposal (if available) on success and error responses in case of attempts at registering multiple resource sets (general idea: Boolean, single ticket) - What is necessary to do in UMA about RSR for standard APIs? - Thread with Adrian - Begin building a comprehensive model for client awareness of scopes and set math at every step - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

In case you haven't seen this
by John Wunderlich 25 Jul '16

25 Jul '16

The National Institute of Standards and Technology ("NIST") has issued a public preview on GitHub (rather than a public comment period) of its changes to its suite of SP 800-63-3 documents on digital authentication: - which consists of 4 documents: - Digital Authentication Guideline - SP 800-63-3 <https://pages.nist.gov/800-63-3/sp800-63-3.html>; - Identity Proofing & Enrollment - SP 800-63A <https://pages.nist.gov/800-63-3/sp800-63a.html>; - Authentication & Lifecycle Management - SP 800-63B <https://pages.nist.gov/800-63-3/sp800-63b.html>; and - Federation & Assertions - SP 800-63C <https://pages.nist.gov/800-63-3/sp800-63c.html>. - which: - supplement OMB guidance, E-Authentication Guidelines for Federal Agencies <https://nymitytools.nymity.com/Reference.aspx?referenceid=603f5c77-5700-4e0…> (OMB M-04-04); and - supersede NIST SP 800-63-1 <https://nymitytools.nymity.com/Reference.aspx?referenceid=3fce0539-73cc-4be…> and SP 800-63-2 <https://nymitytools.nymity.com/Reference.aspx?referenceid=fbe9cd27-3af5-459…> . Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca -- 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

Notes from UMA telecon 2016-07-21
by Eve Maler 24 Jul '16

24 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-21 MinutesRoll call Quorum not reached. Critical mass reached. Approve minutes Approve minutes of UMA telecon 2016-06-30 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-30> , 2016-07-07 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-07>: Deferred. Review spec editing and logistics progress Some news and decisions documented here <https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/public…>. We have removed our generated artifacts from our source repository. They should go elsewhere, either in a KI GitHub repo or in the sort of structure they're in now. The UMA1 language around ordering of client-AS interactions used "non-RFC2119" descriptive verbs for the flow, which seems to have had the salutary effect of allowing the client to go directly to the claims endpoint vs. having to "pass GO", that is, stop at the RPT endpoint first. This relates to the latest "Questions about MPD" thread discussion. James had raised an objection, but doesn't feel strongly enough about it. See IETF RFC 4949 <https://tools.ietf.org/html/rfc4949> for authentication vs. login. Spec editing instruction: - Replace the descriptive flow wording in "phase 2" with normative wording (e.g., from "if the X does something, then the Y does something" to "the X MUST do something...") Including multiple resource sets while registering for a permission ticket Proposed extension <https://08620661282160442115.googlegroups.com/attach/f218681b41266/draft-um…> text that we created once upon a time, with the (one resource set = object, multiple resource sets = array) solution having been chosen. Adrian asks: With a gigantic standard API like FHIR in play, what are the considerations for what the RS needs to tell the AS? There are two choices: Either the RS registers a big resource set such as "a whole EHR" and the AS has extra semantic smarts to know its innards, or the RS has to register all the component parts explicitly and the AS doesn't have to be smart about the sector-specific semantics. The latter doesn't sound very tenable. - The AS is supposed to bear more complexity than the RS. - The AS shouldn't have to peek into the structure to see what it is, but then it's supposed to bear more complexity. Also, the first character is the clue. - The RS shouldn't have to decide what structure to pick. - Then again, the RS should be able to do the simplest thing for the commonest case, which we could guess is the single-resource-set case. - On the third hand, the RS code would be cleaner if it could write arrays all the time. - And this pattern is familiar for AS developers who already deal with multi-value objects. - The RS data model shouldn't take the burden of all-arrays-all-the-time Consensus on object-plus-array. Open questions: If the resource server's request is authenticated properly but fails because one or more of the requested permissions has an invalid resource set identifier or an invalid scope, then... [TO BE DISCUSSED: What should happen? Should a partial result be registered? If so, what should be the response? Or should the whole thing fail? And do you get back one or multiple tickets? *AI:* Justin: Write up a proposal for success and error responses. He says: Boolean, single ticket, keep it simple. General agreement. Logistics We have calls scheduled for the next two weeks, and then August 12 there's a cancellation. Attendees As of 14 Jul 2016 (pre-meeting), quorum is 7 of 12. (Domenico, Kathleen, Sal, Nagesh, Andi, Robert, Paul, Agus, Maciej, Eve, Mike, Sarah) 1. Sal 2. Maciej 3. Eve 4. Mike Non-voting participants: - Scott - Justin - François - Adrian - James - John - Colin - Ishan - Jin - George Regrets: - Andi - Domenico *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 7

Notes from UMA legal telecon 2016-07-22
by Eve Maler 22 Jul '16

22 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-07-22 - Review UMA Roles and Responsibilities Primer <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> Attending: Eve, John, Sal, Ann, Kathleen, Colin, Adrian, Jon, Scott (Maciej regrets) We reviewed the primer and made changes dynamically. We discussed whether "Alice and Bob" are appropriate as standard RO and RqP names, given their history as equal peers in PKI, vs. their asymmetrical nature in UMA. UMA's historical goal is to empower the RO role in an ecosystem fashion a la Eve's 2008 diagram from the Digital Contracts MIT event, even if instances of a running UMA protocol are indeed asymmetrical, since the RO has an "agent" – the AS – working on her behalf whereas the RqP doesn't. Of course, there's an admittedly asymmetrical part of the UMA protocol called trust elevation where the RqP may have to supply or direct services to supply information about themselves, which could be UMA-protected, so the RqP could have an "agent" acting on their behalf too. In short, while they're not peers at an "individual instance of the protocol" technical level, it's possible that they're similarly protected at the technical, contractual, and regulatory layers. Self-regulatory structures are the common theme coming out of the list of "Additional Discussion Topics", which we spent a lot of time on. Some of those structures will be shaped by supply chain necessities – see, for example, how UPS and FedEx end up with similar contractual outputs. We think that once we have our "Tech/Contract/Reg" framework, we could spin out white papers on each of the additional discussion topics, and likely liaise more effectively with the IDoT, IRM, and BSC efforts in Kantara. (Be sure to see the notes so far <http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29…> from the BSC group.) We reviewed the scenario in the Tech section. Scott asked: Do we want to draw the equivalence between the federated identity progress and federated authorization? Eve thinks this depends on whether we're writing for an audience that understands federated identity trust frameworks. Adrian goes by the "There's only one Alice" mantra – the AS shouldn't be "domain" (sector) specific. This is the personal AS viewpoint. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0