- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2016-08-04
by Eve Maler 03 Aug '16

03 Aug '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04 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> , 2016-07-14 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-14> - Logistics items - Telecon interruptions - I-D expirations - 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> - Client awareness of scopes and set math <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02> - How to give resource set ID context to standardized resource set and scope semantics profile idea <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-28> ? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Transferring standardized resource set and scope semantics out of band: digging deeper
by Eve Maler 01 Aug '16

01 Aug '16

Last Thursday we got this far in our understanding about transferring standardized resource set and scope semantics (say, as captured in the FHIR API or some other large, complex API implemented by multiple independent service operators) out of band of the UMA RSR process: http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-28 The AS would declare that it's using the protection API extensibility profile, meaning that it's prepare to go outside the normal AS-RS communication route for some part of its interaction with RS's. The community around the relevant API would define an extension profile. (We didn't talk about this, but such an extension profile would define an URI as an identifier, and this URI would be referenced in the AS config data/discovery document, advertising its compatibility with that profile.) The profile would, we believe, possibly involve explicit registration of a "bootstrap" resource that signals implicit registration of other resources that have standardized "type" fields. It occurs to me that what's incomplete about this scheme (at a minimum -- there may be other things missing) is that, in explicit RSR, we register "instances" and not "types" of resource sets, and the RS gets back from the AS a specific resource set ID that has been dynamically created for it, and can't *tell* the AS what resource set ID it wants. E.g., let's say that the RS registers a "bootstrap resource set" of "FHIR:EHR" type with the AS on Alice's behalf (and gets back a resource set ID of "foo"), which the HEART-UMA-FHIR profile defines as signaling that a whole bunch of other "sub-resource sets" of other specific types should be automatically registered too, like one with the "FHIR:medicationlist" type and one with the "FHIR:allergylist" type and whatever. What, exactly, are their resource set IDs in the Alice context? Since we had wanted to create these implicitly and not with an API call, how would the RS be informed of what these are? Or do we have to actually invent new bulk ways of doing this in-band? (In a draft version of the RSR API, we used PUT instead of POST, which enabled the RS to dictate its own resource set IDs, but gave that up for very good reasons.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

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