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

Documenting UMA publication workflows
by Eve Maler 18 Jul '16

18 Jul '16

Hi folks-- Hope you are enjoying post-Christmas reentry or more holiday time, or whatever the case may be. Maciej and I are working on publishing the new Recommendations, and due to that, I unearthed the permanent/symbolic link information that I promised to Justin; we thought it would be a good idea to document the processes here -- and in the GitHub readme... It seems to work pretty well for now given that there isn't that much to the entire publishing process for our WG or others, but if you see ways to improve it for the future, let us know. After completing a draft spec revision cycle and getting it approved: 1. Edit the draft-uma-core-vn_n[_n] and draft-oauth-resource-reg-vn_n[_n] sources to change from Status #3 to #4 (see below), leaving the previous date in place. 2. Run the stylesheet over the XML sources to produce .html outputs, review the results as required, sync GitHub, and upload the last drafts by FTP (Eve and Oliver can do this). 3. Save the draft-uma-core-vn_n[_n] and draft-oauth-resource-reg-vn_n[_n] sources off to new files in the repo starting with rec- instead. 4. Change the Status section of the new files from #4 to #5, the date, and any other metadata (some of this has to be done in the stylesheet, which is in the repo). 5. Update the two specs' References links to each other in the Reference section. 6. Run the stylesheet over the XML sources to produce HTML output with .html extensions, review the results as required, sync to GitHub, and FTP the HTML results to the website (Eve and Oliver can do this). 7. Get symbolic links created (see below) from the versioned rec- HTML links to generic links (Oliver can do this). After launching a new draft spec revision cycle: 1. Save the rec-uma-core-vn_n[_n] and rec-oauth-resource-reg-vn_n[_n] sources off to new files in the repo starting with draft- and having the agreed new version numbers instead. 2. Edit the Status section from #5 to #1. 3. Proceed to edit the new drafts, and periodically produce HTML results that can be uploaded through FTP. 4. Get symbolic links created from the versioned draft- HTML links to generic links (Oliver can do this). Here are the stages of the Status section (embed links throughout as appropriate): 1. This document is a draft technical specification produced by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home>. 2. This document is a Kantara Initiative Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home>. 3. This document is a Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and certified by the Leadership Council to undergo a Kantara All-Member Ballot. 4. This document is a Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and certified by the Leadership Council to undergo a Kantara All-Member Ballot. The Ballot having passed, this document has been superseded by the Recommendation version of the document. 5. This document was developed by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and approved by the Membership of the Kantara Initiative <http://kantarainitiative.org/> as a Recommendation. Here is how the symbolic links work: https://docs.kantarainitiative.org/uma/rec-uma-core-vn_n[_n].html - Permanent link to specific Core Rec https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-vn_n[_n].html - Permanent link to specific RSR Rec https://docs.kantarainitiative.org/uma/draft-uma-core-vn_n[_n].html - Permanent link to specific Core Rec https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-vn_n[_n].ht… - Permanent link to specific RSR Rec https://docs.kantarainitiative.org/uma/rec-uma-core.html - Symbolic link to latest Core Rec https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg.html - Symbolic link to latest RSR Rec https://docs.kantarainitiative.org/uma/draft-uma-core.html - Symbolic link to latest Core draft https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html - Symbolic link to latest RSR draft *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 2

Re: [WG-UMA] Draft minutes of UMA telecon 2016-02-18
by Eve Maler 28 Feb '16

28 Feb '16

Interesting indeed. In the WG call yesterday, we talked about focusing on four UMA topics at IIW, and one of them was our legal "model text" work. I would love to learn more about how these domains are used in practice, and see where the business-legal frictions might come into play if they were used as authorization servers. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Sat, Feb 20, 2016 at 9:23 AM, Phillip J. Windley Ph.D. <windley(a)gmail.com > wrote: > BYU and several other schools do a Domain of One’s Own project with > students. BYU has about 2000 domains right now (these are com, org, net, > and us domains that the student picks and owns and can take with them after > graduation). The point is to teach students about managing their own online > identity independent of the administrative identities they get elsewhere > (the school, Facebook, Gmail, etc.) and give them experience in being > independent digital citizens. The domains are used for everything from > class projects to rock bands. > > As part of that effort we’ve been working on ways the domain could host > applications the student might use to interact with the school and other > entities. As a counterpoint to our University API project, we also have a > Personal API project. The first applications will likely be student > profiles and portfolios. > > The question about manage authorizations always comes up. I always have > imagined that the domain (standard Cpanel-based hosting account) would have > some kind of AS running in it, but have never worked through the details. > So, FWIW, there’s another personal AS scenario. > > On Feb 20, 2016, at 9:51 AM, Eve Maler <eve(a)xmlgrrl.com> wrote: > > I agree with you both that it's technically feasible for a single person > to run a personal AS. > > From a practical "ecosystem growth" standpoint, I wonder whether certain > other service/app operators might have some (irrational? perceptual?) issue > with dealing with an AS whose Operator is the Authorizing Party. We already > know certain RS's (*coff* hospitals) are nervous to outsource authorization > to a third party at all (the genesis of the Binding Obs work). > > I wonder if the best shot for people running their own personal AS's might > actually be a "smart home hub". We're already seeing home VPN devices > billed as "privacy" products, along with other devices that control > multiple other IoT thingies. > > Eve Maler (sent from my iPad) | cell +1 425 345 6756 > > On Feb 19, 2016, at 7:53 AM, John Wunderlich <john(a)wunderlich.ca> wrote: > > Adrian; > > Owning/operating an AS is not unrealistic technically. It’s unrealistic In > the same way that most people CAN change their own oil in their cars, but > don’t. > > I suspect that most people’s view - even after an explanation of how UMA > works - is that it would be too much trouble to own/manager their own AS. > If/when the AS becomes an app on their phone, or a key fob with a one > button press functionality, (assuming that carrying your AS with is a good > thing) then the case would be different - and would suggest a separation of > AS from IdP(s). > > Sincerely, > *John Wunderlich* > *(@PrivacyCDN)* > > <PastedGraphic-4.tiff> <http://privacybydesign.ca/> > <http://privacybydesign.ca/> > > > <http://privacybydesign.ca/>Privacist & PbD Ambassador > <http://privacybydesign.ca/> > > > > > On Feb 19, 2016, at 10:14, Adrian Gropper <agropper(a)healthurl.com> wrote: > > John, > > We seem to agree that the AS is naturally separate from whatever IdPs and > credential brokers will evolve. > > The opportunity to own one's AS in the cloud is more realistic every day. > A microservices architecture like AWS Lambda can expose HTTPS endpoints > with Let's Encrypt certificates without the hassle of managing OS and OS > security for a VM. AWS Lambda can run a personal UMA AS written in Node or > Python (like HIE of One) using almost no resources and might cost less than > the $10 / year that I pay for the personal domain. I see an UMA AS becoming > like the email forwarding service offered for free by some registrars with > just a more complex user interface. > > Adrian > > On Fri, Feb 19, 2016 at 9:54 AM, John Wunderlich <john(a)wunderlich.ca> > wrote: > >> It seems to me that this elides several use cases. If we set aside the >> currently unrealistic expectation that each person will own one or more >> AS’s, then the most likely location for a self-owned AS is in the home, or >> in a cloud service provided to the individual (a cloud home so to speak). I >> can see where I’ll want to use an authoritative IdP for some kinds of >> transactions and identities - health (hospital as IdP) and finance (bank as >> IdP) - but I can see multiple scenarios involving social identity where I >> would want to self assert to have the capability for multiple (disposable) >> identities. This isn’t just the case for teenagers and trolls, but would >> also be the case for human rights workers and democracy activists in any >> number of countries. >> >> Sincerely, >> *John Wunderlich* >> *(@PrivacyCDN)* >> >> <PastedGraphic-4.tiff> <http://privacybydesign.ca/> >> <http://privacybydesign.ca/> >> >> >> <http://privacybydesign.ca/>Privacist & PbD Ambassador >> <http://privacybydesign.ca/> >> >> >> >> >> On Feb 18, 2016, at 19:47, Eve Maler <eve(a)xmlgrrl.com> wrote: >> >> A question to Adrian about the goal of making an AS lighter and more >> generic so that each individual can own one: Do you think it's likely that >> the AS function and the IdP function are likely to remain entirely >> separate, and not be co-located in at least some instances? (I'm guessing >> your answer will be yes, because you've separated out the "lightweight AS" >> and the "RS-as-IdP" roles here, but I may be wrong.) >> >> >> >> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl >> >> >> On Thu, Feb 18, 2016 at 11:05 AM, Adrian Gropper <agropper(a)healthurl.com> >> wrote: >> >>> To be clear, my suggestion about IdP in the #wideeco is for the #wideeco >>> AS to be given the option of using the RS as Bob's IdP. That is very >>> different from the RS being the IdP and AS if that's how I read the >>> minutes. >>> >>> In general, I'm looking for ways to make the AS lighter and more generic >>> so that each individual can own one. In the HIE of One brand #wideeco >>> model, the UMA AS is also always an OpenID Connect Client so that any RS >>> that chooses to support OIDC Dynamic OP can offer this as part of the >>> resource registration agreement with a #wideeco AS. This also enables the >>> AS to register other well-known IdPs like Google and make these available >>> as a NASCAR to Bob. As blockchain ID catches on (onename >>> <https://bitcoinmagazine.com/articles/onename-launches-blockchain-identity-p…> >>> and uPort >>> <https://medium.com/@ConsenSys/uport-the-wallet-is-the-new-browser-b133a83fe…>), >>> the #wideeco AS will be able to offer this as an option as well. >>> >>> Adrian >>> >>> >>> >>> On Thu, Feb 18, 2016 at 1:09 PM, Eve Maler <eve(a)xmlgrrl.com> wrote: >>> >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> WG-UMA mailing list >>>> WG-UMA(a)kantarainitiative.org >>>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>>> >>>> >>> >>> >>> -- >>> >>> 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/ >>> >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/wg-uma >> >> >> >> >> 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. >> > > > > -- > > 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/ > > > > > 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. > > <signature.asc> > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma > > >

2 1

Notes from UMA legal telecon 2016-02-25
by Eve Maler 26 Feb '16

26 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-02-26 - Resource owners and those acting on their behalf: what language do we need to support the distinction? Any additional use cases? Any additional insight on technical design patterns? - We said we'd try to conclude this decision-making process by this week, and then move on to the decisions about RS actions in contradiction. Attending: Eve, Adrian, Ann, Andrew, Mark, Sal, Kathleen, John Kathleen had summarized it in our WG call yesterday that this is an "owner" and an "on behalf of" problem. Adrian asks: Is it clear that there need to be separate credentials for these two roles (something like subject and custodian)? Kathleen's work at HL7 includes three roles: the *subject* of consent directive (of governed information), the *grantor* (the consentor who grants access), and the *grantee* (the one to whom access is delegated). Eve is familiar with a project where UMA is being contemplated where subject and delegate are the terms used, where she suspects (*subject* +*grantor*) and *grantee* map perfectly onto Kathleen's terms, and she knows they map exactly onto UMA's *RO* and *RqP* terms. Let's put the "third term" aside since it seems there's no controversy about the mappings (for the moment), and concentrate on the "split RO" nature of the use cases in front of us. Do we have to distinguish "who logs in to the AS" vs. "who logs in to the RS only"? Adrian asks: In our use cases from last week, are there separate credentials? We need to know the exact UMA design pattern we're looking at to know the answer, because otherwise the specific identity ecosystem in place is unknown. Andrew suggests: Is the question really about whether the RSO cares who the ASO is? Let's say a hospital IT department is the RSO and the healthcare insurer (Eve adds: or EHR SaaS vendor or government agency or whatever...) is the ASO. Going back to the key issue: Adrian presumes that the AS presents a certificate and the RS gets to look at that certificate and see if it trusts it. But Eve points out this is off-track for the subject of this call. Any AS cert is for the whole AS. Let's return to (*subject*+*grantor* ). Regarding the terms coming from HL7, FHIR is taking this nomenclature work even farther. Eve wonders: Could subject and grantor suffice as terms for us, even if the subject isn't even literally the data/PII subject? Like, e.g., what if the "subject" created the digital artwork that is being sold and the grantor is managing access to the painting on behalf of the subject because they're no longer legally competent to be party to contracts? In health, a donor or cadaver might not be donating data, but body parts! (?) The current theory/hope is that *Subject* could be a good new term for the "true resource owner" who might not be legally competent or might not be in a position to manage resource access at the AS. (Note that "control" is the verb we use on the UMA marvelous spiral architecture diagram to denote what the RO does at the AS.) If we need to get more specific in any of our model clauses regarding resources that truly contain PII, perhaps we need to clarify in the definition that UMA allows for resources not to contain PII, and then define a more specific term, *Data Subject* or *PII Subject* or *Resource Subject* (as discussed in notes below), specifically for resources that do contain it. (Do we also have to define the term *Resource* and/or *Protected Resource* in our model definitions?) More current theory/hope: *Grantor* could be a good new term for the "guardian" of a legally incompetent Subject, or designated "proxy"/"agent" for a legally competent Subject, who exclusively manages resource access at the AS on their behalf. [Added after the call:] Eve's theory about the UMA design pattern in this case is this: The Grantor is the *only one* that interacts with the AS (e.g., logs in there, creates policies, etc.) If the Subject is capable of managing resources in an online fashion ("manage" is the verb we use on the UMA marvelous spiral architecture diagram to denote what the RO does at the RS, but also the verb we use to denote what the RqP does at the client), then in fact what could happen is that the Grantor sets up policies for the Subject to become an RqP to their own resources, accessing them through RS-that-is-also-a-C, and requiring that the Subject use the same AS as the Grantor to enable full Grantor oversight capabilities. (This is a known limitation due to #wideeco realities.) More current theory/hope: We could replace *Authorizing Party* with Subject and Grantor. More current theory/hope: *Grantee* could be a good new term for Requesting Party. *AI:* Kathleen: Share HL7-based definitions of subject and grantor (and grantee) with UMA WG so we can try out definitions for our own purposes. (ISO standard basis for the definition – what is the ISO number? -- can't be shared because they're not free standards.) *AI:* Adrian: Work with Kathleen to capture the "joint control" of painting resource example and share with the list. *AI:* Eve: Add GitHub issues for the new model definition ideas. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

26 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-26 - Resource owners and those acting on their behalf: what language do we need to support the distinction? Any additional use cases? Any additional insight on technical design patterns? - We said we'd try to conclude this decision-making process by this week, and then move on to the decisions about RS actions in contradiction. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

URGENT: replacement number for UMA legal call - TurboBridge giving me problems
by Eve Maler 26 Feb '16

26 Feb '16

Please switch to this instead: +1 (605) 562-3000 919-726# Sorry for the inconvenience! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Is it UMA, HEART, or X?
by Adrian Gropper 25 Feb '16

25 Feb '16

How does a Resource Server operator advertise that they offer policy-based OAuth client access? (If they just want to support clients that they register directly, they can simply claim OAuth2). Let's consider a connected lock vendor wants to make a claim that their lock works with "standard" OAuth authorization servers rather than asking all of the visitors to install yet another app on their smartphone. Let's also consider a hospital with a FHIR API that also wants to claim it works with "standard" OAuth2 authorization servers. What label would apply to these authorization servers that says to folks: "Your standard AS accepted here?" Is it UMA, HEART, or do we invent some other trademark? 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 0

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

25 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-25 MinutesRoll call Quorum was reached. Approve minutes Minutes of UMA telecon 2016-02-18 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18> approved. Report from legal meeting The legal subgroup is working on an interesting issue that tackles the subtleties behind "who is the RO" – not at the "T" level, where the UMA protocol has no doubt, but at the "B" and "L" levels, where there are layers of "is the one" and "is acting on behalf of the one". Kathleen notes that HL7 is right there with us working on the exact same issues. The goal is to define our terms clearly so that we can craft our model clauses around the operation of the protection API (the operator of the AS, the operator of the RS, and the authorizing party or whoever is acting on their behalf) accurately. Adrian is driving towards a particular goal of an AS that is operated by the RO themselves. Charter-bashing Let's take charter <https://docs.google.com/document/d/1cv7MLdpC1SMubREbZX7L8E4YUPCAzKPwOCFBky6…> review as homework for our meeting two weeks from now. Upcoming F2F opportunities You can find UMAnitarians at HIMSS and RSA. See Gluu's blog post <https://www.gluu.org/blog/gluus-rsa-conference-2016-events/> for some RSA opportunities. Who is definitely attending IIW? Eve, Mike, Adrian, Jin, Maciej, George. Who is possibly attending? John depending on his China gig situation, Andrew Hughes based on what we might work on, Ishan based on work schedule. Would there be interest in focusing on conformance testing as a discussion topic at IIW (again)? Adrian is interested, from a very specific perspective: having an AS reference implementation. Mike notes that there are several open-source implementations that could be reference implementations, and there are several use cases, so we don't seem to lack for them. Is a reference implementation the job of the WG(s)? John suggests something more like the W3C Validator. In fact, the budget request includes a hosted test harness that would (initially) test authorization servers. Sounds like working on what use cases to test would be a winner. Eve also suggests working on, and getting people up to speed on, our model text. Mike also suggests doing some "UMA marketing". Eve is up for that, but not for self-flagellation. [image: (smile)] What about the UMA/blockchain connection? This is a very good point. Thomas and Jim have been working on this area. Thomas has a slide deck <https://hardjono.mit.edu/sites/default/files/documents/CommonAccord_Provena…> on this. We have four UMA-related topics of interest we'd like to convene sessions about at IIW. Issue #239 spec review Should we totally replace the requesting party claims endpoint, or write the configuration data piece so as to invent a new "enhanced claims-gathering security endpoint" so that people could deploy UMA-with-lesser-security and UMA-with-tighter-security at the same time? We've modularized the extension so that we could work on the mitigation ASAP and for flexibility's sake in pacing our UMA V.next plans. We seem to have achieved that. The group has no appetite to invent a lesser-security endpoint for form's sake. *AI:* Maciej, Eve, Dom: Revise the spec and share with the list for more review before we publish more widely. #wideeco Deferred. Attendees As of 18 Feb 2016, quorum is 6 of 11. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah) 1. Eve 2. Robert 3. Domenico 4. Maciej 5. Kathleen 6. Mike 7. Sal Non-voting participants: - Adrian - James - Ishan - John - Scott - George - Jin Regrets: - Andi - Sarah *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

APAC-friendly call cancelled
by Eve Maler 25 Feb '16

25 Feb '16

Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 1

Agenda for UMA telecon 2016-02-25
by Eve Maler 24 Feb '16

24 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-25 Date and Time - *Thu Feb 25,* 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-02-18 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-18> - Reports from sync and legal meetings - Charter-bashing <https://docs.google.com/document/d/1cv7MLdpC1SMubREbZX7L8E4YUPCAzKPwOCFBky6…> - HIMSS, RSA, and the Non-Profits on the Loose event - IIW planning - CIS/legal/interop? - Review #239 spec and doc; next steps - #wideeco analysis and potential solution collection - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: APAC-friendly sync 2016-02-25 [see note below]
by Eve Maler 23 Feb '16

23 Feb '16

*[NOTE:* I may possibly be delayed in joining the call by an appointment that could run long. If you plan to join the call and are not yet part of our "UMA Chat" Skype group, please send me your Skype handle to be added so that I can keep you apprised in real time. If you're not on Skype at all, let me know that.*]* - *Thu Feb 25* at APAC-friendly times - Voice: Skype: +99051000000481, 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) - See the UMA calendar for additional dial-in and timing details (e.g., the call time = *Wed Feb 24 4pm PT*): http://kantarainitiative.org/confluence/display/uma/Calendar If you wish to be added to the calendar invitation, send me a note. If you wish to be added to our Skype chat group to receive reminders before I open the bridge, include your Skype handle. The standing agenda is to review recent WG progress, collect participant feedback, check on action item status, and attend to any other relevant business. Others besides those in APAC-ish regions are welcome to join. This sync series has been useful for some who have a standing conflict with our weekly WG calls. However, the sync series doesn't "count towards quorum" if you're a voting participant. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0