September 2019 - WG-UMA - mailman.kantarainitiative.org

Notes from 2019-09-10 UMA business-legal telecon
by Eve Maler 10 Sep '19

10 Sep '19

https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 2019-09-10 Attending: Eve, Andi, Nancy, Domenico, Vlad, Cigdem Our agenda for today: "Start to document the full value and structure of a final "WG draft report" (or is it a spec?) deliverable that we can put together with all this fodder based on our work over the last several months. We had said our deliverable timing would be September... :)" The value-add of "UMA-biz-legal-relationships" above and beyond "UMA-technical", we think, is that (e.g.) the operator of a service or client, or the RRA or requesting party, can auditably prove what another party needs it to prove regarding a commitment or promise it has made to the other party. And if necessary, if enforcement can't take place at a technical level, it can take place in a court of law as required (because you have audit logs and non-repudiable artifacts to point to). All of these loosely coupled parties need to cooperate and have their interests sufficiently aligned to have selective sharing work. See examples listed in the Sources of liability tension section on the UMA Legal page here <https://kantarainitiative.org/confluence/display/uma/UMA+Legal>. Which party cares most about changes, additions, and subtractions in the RRA role? The ASO. The PAT is the "thin reed" of technology (a technical artifact) that binds the ro, as, and rs. Is it enough to give us a technical means of controlling lots of biz-legal-relationships scenarios? We have several sets of scenarios. One is the ro/RRA state diagram. A second could be a rqp/Requesting Agent/Requesting Party state diagram (that doesn't exist yet). A third that doesn't have a diagram yet is where only policies (a non-UMA artifact) change in response to the ro/RRA sharing on the basis of a relationship. Example: Alice wants to share a set of resources with "whoever is in the 'spouse' relationship" with her. If she indicates that no one is now in that relationship, her policies reconfigure and sharing ends. What's attractive is that both Alice and the ASO and RSO(s), by extension, can all know that sharing ended even if it's a big complicated set of resources that was shared. In this third case, is it really in our scope to be talking about these policies? We could say they're out of scope, but some "consent" (could be described as authorization policy and sometimes is) data formats are standardized, e.g. in HL7 (a Consent record) and XACML, and it is sometimes desired to "federate" consent servers, and even though UMA doesn't standardize policy data formats, it's sort of an adjacent use case. It exists on a continuum with UMA use cases. Plus, all three sets of scenarios seem to end up needing to be combinatorial at the end of the day. Note that HL7 federated consent implies that you have a federated consent server that you can read and interpret. Consent itself is PHI (personal health information). While UMA technically doesn't require policy conditions to be stored at an AS (this is deployment-specific), it does assume policy-setting can happen at the AS; there are numerous examples in the specs throughout. And the privacy considerations in UMA FedAuthz <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0…> talk about PII involved in resource registration and policy-setting only implicitly ("the authorization server may come to learn a great deal of detail about Alice's health information just so that she can control access by others to that information"). For example, if Alice tells her AS to share all her data except HIV-related data, that exposes that she may have HIV-related data. The HEART profile for OAuth/FHIR <https://openid.net/specs/openid-heart-fhir-oauth2-1_0.html#rfc.section.8> tries to protect against assumptions about existence of confidentiality/sensitivity scopes, but it's still hard not to make assumptions. Just because you *can* separate the AS and RS, it doesn't mean they're necessarily in separate organizations/domains. Some privacy considerations may not apply in cases where they are run by the same organization. Let's start drafting collaboratively. A GDoc is a great way to start, following the (Kantara-inflected) RFC style. Andi and Cigdem are willing to jump in on co-authoring with Eve. Nancy is willing to be backup [image: (smile)] after the next two weeks. AI: Eve: Start a skeleton draft doc for next time. AI: All: Sort through the next two batches of scenarios and work on the wording we're using in the second scenario batch in our next meeting. *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: UMA business-legal telecon tomorrow (30min earlier than usual)
by Eve Maler 09 Sep '19

09 Sep '19

We meet *7:30am PT* on Tuesday at https://global.gotomeeting.com/join/857787301 -- see our calendar here <https://kantarainitiative.org/confluence/display/uma/Calendar>. Previous notes are here <https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…>. Our spreadsheet is here <https://docs.google.com/spreadsheets/d/1QT5LR_ibpwYwpD_XLQ1tB7OLXbdaT6Oi9aj…> and some new diagrams are in our "business model: mapping graphics" deck <https://drive.google.com/open?id=1uigCMQI_TKuFyOstQTngYuZaqs36wwbE3BBjBB7xG…>. Trying to access these links will send me a notification to share the docs with you with your preferred ID, if I haven't already given you access. Agenda items: - Start to document the full value and structure of a final "WG draft report" (or is it a spec?) deliverable that we can put together with all this fodder based on our work over the last several months. We had said our deliverable timing would be September... :) *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2019-09-05
by Eve Maler 05 Sep '19

05 Sep '19

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-09-05 MinutesRoll call Quorum was reached. Approve minutes - - Approve minutes of UMA telecon 2019- <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20> 08-08 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-08> Deferred. Status on UMA2 IETF I-Ds Our I-Ds have expired. Even though we (meaning Eve) didn't minute it very thoroughly, we did conclude (didn't we?) that we wanted to go the independent/individual submission route. We would need to resubmit the drafts and change the tag to Informational. Then we'd have to get in touch with the area directors. There are two formatting issues created in making the I-Ds – these are totally I-D artifacts: - The UMAGrant link in the references section of FedAuthz is broken. - In the UMAGrant spec, the union/intersection set math symbols didn't come out right. In addition, we may want to consider absorbing a couple of GitHub issues that would make this turn into an UMA 2.0.1 because of our semantic versioning commitment: - 362 <https://github.com/KantaraInitiative/wg-uma/issues/362> (IANA registration of "UMA" scheme) - #362 takes an email and some time for registration (assuming they accept it). Our argument for inventing the scheme was that a client playing in both UMA-grant and other-OAuth-grant ecosystems would need to get the "UMA" scheme signal in order to know how to respond, so it's needed for interoperability. We would like to *register the scheme*. - 361 <https://github.com/KantaraInitiative/wg-uma/issues/361> if it's a non-normative change to metadata) - #361 needs investigation on our part. Are we compatible with the constraints on the .well-known path? We say in UMAGrant Sec 2 <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#as-c…> that "The discovery document MUST be available at an endpoint formed by concatenating the string /.well-known/uma2-configuration to the issuer metadata value defined in [OAuthMeta]". So if the issuer has a path in it, our language might break. In principle, most people don't use paths unless they deploy a multi-tenant platform, and that's when they run into issues with our now-OBE language. Some options: 1) We could put in non-normative language that warns people that, say, they could run into problems with multi-tenant path use cases or something given that we're not pointing to the final metadata RFC and this could be changed in a future version. Or 2) We could just not do anything for now. The sentiment is to choose *option 2*: Don't do anything for now. - 360 <https://github.com/KantaraInitiative/wg-uma/issues/360> (typo) - #360 is easy to decide. *Fix the typo.* An UMA 2.0.1 is still "UMA2". It's a patch release that fixes a couple of unimportant bugs. George and Thomas speak in favor. We had looked up whether Kantara has an errata process and it sort of may, but this should be better since most people, especially devs, have a strong expectation of what patch numbering means. We should publish any patch spec versions (on the KI site) in the same place as the original version, such that if you expected to get "UMA 2.0.0" but there is, say, an "UMA 2.0.2" available, you get that in the same location. An "UMA 2.1" would be in a different location because semantically that's significant. Nancy notes that a use case where the AS is not the IdP is something she's running into now. Eve is finding that this is where deployments might typically choose interactive claims gathering, PCT usage, etc. Contributing to XYZ use cases Justin sent this compendium of use cases for XYZ <https://mailarchive.ietf.org/arch/msg/oauth/v8TdkruCzwH43FMKS598IC2Sheo> to the OAuth list. OAuth2 had baked into it the concept of "grants", and that meant a lot of things got squished into grants. Extensibility is in XYZ, but it comes in different ways. Might this mean there won't be an explosion of specs over time, the way OAuth2 was susceptible to? Weirdly, client IDs aren't there, error messages on the front channel... They're not there because you don't need them. We should be sure to capture, not just use cases that OAuth is struggling with, and use cases that UMA solved because OAuth couldn't do them on its own, and use cases that UMA is struggling with, but also use cases that people have pressed OAuth and UMA into service for "just fine" as far as they are concerned but they're not at all sure how XYZ would solve. George would like to be able to define and name an extension with a clear set of functionality. UMA-related use cases Eve would like us to write up: - Alice-to-Alice sharing (RO-to-self) - Proactive Alice-to-org sharing (RO-to-client developer, so to speak) - Bob is assured to a certain level that Alice is who she says she is (strong Alice-to-AS binding or "CIBA-like") - Transactional and long-term management of sharing of preferences with service providers She would be grateful for volunteers to help draft some of these for next week. IETF 106 is in November in Singapore. Justin will be there in person. He's working on hopefully having them hold a BOF on XYZ there. Thomas advocates for a new WG. Nominations for chair and vice-chair Voting deferred. We do have a meeting next week. Attendees As of 16 Jul 2019, quorum is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Peter 3. Thomas 4. Maciej 5. Eve 6. Cigdem Non-voting participants: - Pete Palmer - George - Justin - Nancy - Lisa - Vlad *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

FW: [OAUTH-WG] Use cases for XYZ
by Cigdem Sengul 05 Sep '19

05 Sep '19

From: Cigdem Sengul <Cigdem.Sengul(a)nominet.uk> Date: Wednesday, 21 August 2019 at 16:21 To: UMA WG <wg-uma(a)kantarainitiative.org> Subject: FW: [OAUTH-WG] Use cases for XYZ Hello, I will believe some of you will find interesting what Justin shared in the OAUTH-WG mailing list, if you’ve not already seen. --Cigdem ---------- Forwarded message --------- From: Justin Richer <jricher(a)mit.edu<mailto:jricher@mit.edu>> Date: Mon, Aug 19, 2019 at 9:04 PM Subject: [OAUTH-WG] Use cases for XYZ To: OAuth WG <oauth(a)ietf.org<mailto:oauth@ietf.org>> As promised in Montreal, I have started to pull together use cases that fit XYZ’s model better than they fit traditional OAuth. While I’ve been able to work out how XYZ works for the most common OAuth deployments and extensions, I think the real interest is in the new spaces where OAuth doesn’t work out as well. The list here is far from comprehensive, of course, and I’d like to keep building this out. I plan on putting things into a more formal structure and getting them onto the https://oauth.xyz/ website in the near future alongside any others that I gather. Ephemeral Clients. The OAuth model puts the notion of a “client” application front and center, and this makes sense from OAuth’s roots as a way to connect two web servers together. We’ve seen that this breaks down in different ways when we have SPA’s, mobile app instances, etc. Dynamic Registration helps, but with truly ephemeral clients you end up with having a lot of orphaned applications registered into the AS. In the last few years, OAuth has been trending away from pre-registration of all trust material into enabling more runtime keys and secrets. Extensions like PKCE, DPoP, OAuth-MTLS, and Token Binding are all based on this notion. In XYZ, the “transaction” is the core component of the model, and everything hangs off from that. As such, a client application that identifies itself to a new AS, gets a token, then disappears with its tokens is a reasonable model that leaves no trace behind. Distributed RS’s. In highly distributed spaces with common APIs, such as a distributed social network, the RS’s all need to recognize not only the token but also who the token represents. OAuth has some pieces that let you tie something like this together, such as a JWT with key discovery based on the issuer of the token, but this doesn’t lend itself to use with ephemeral clients and bound tokens where the RS would need a way to figure out how to get to the keys. This kind of thinking extends to APIs deployed as micro services behind gateways, or lambda functions on an elastic cloud. What serves an “API” endpoint isn’t what it used to be, and I think we’ve got a better starting place with XYZ to make the lives of RS developers easier by having clearer mechanisms to bind tokens to both the rights they represent and the presentation mechanisms they need. Bound Access Tokens. Everything is bearer tokens in OAuth2. Yes, we’re getting better about this with DPoP and OAuth-MTLS, and I support this work extending OAuth 2. But that’s far from complete or widely used. And what’s really weird, when you look at these, is that we’re not even using some of the half-baked extension points that we :do: have in OAuth 2, such as token types. We really shouldn’t be calling things “Bearer” tokens anymore when they require you to do other things on top of presenting the token, like using MTLS with a specific cert. Plus we’ve got a lot of conflation between people who want to pack keys into the tokens themselves vs. having the keys referenced by the token, which leads to confusion around what things like RFC7800 actually provide and define. XYZ gives us an opportunity to have a much clearer model for what an access token is, and how it gets bound to a key and presentation mechanism of various types. Bearer tokens still work here, too, but they become one among many citizens, like we always intended OAuth2 to have. Multiple Parties. OAuth assumes that the Resource Owner is the person operating the client application. UMA extends this to allowing the Requesting Party to be the one using the client, but it generally doesn’t collapse cleanly into the cases where the RO :is: the party using the client since the claims gathering endpoint and the authorization endpoint aren’t quite the same in concept. UMA’s also arguably pretty complex, but I think it :had: to be in order to fit into the OAuth2 world. And then we have extensions in the identity space like CIBA which have multiple channels of interaction with potentially multiple users. We’ve also got the Device Flow which allows multiple channels connected by a real-world artifact (the user code), and I know of at least one deployment where the interactive page where the code is entered is under the control of someone other than the resource owner, since it’s a transitive trust model at play. This is an off-label use, which XYZ can make much more explicitly built-in. By separating the notion of the nature of the software from the nature of the user’s interaction, we can address a wider array of multi-party configurations without OAuth’s same core assumptions. Nat’s already talked about this kind of thing here on the list, and I think flexibility around who does what is going to be a key difference. Known User. When the client knows something about the user, it should be able to express that to the AS as part of the transaction request. OAuth doesn’t have any place for this to happen, since most interactive flows start from the front channel. The one core flow that does allow this is the resource-owner password grant, which of course exposes the client software to a user’s memorized shared secret (their password). It can’t be used with any kind of challenge-response or assertion-based system. We don’t have any way to pass assertions or claims about the user, unless we wanted to use the token exchange grant — and I would argue that this is abusing the definition of “token” in this space and getting us into WS-* territory. One stop gap that I know of in the wild is to use token exchange to present a user-token to the AS, and then branch behavior: if the exchange works, use the resulting token. If the exchange fails (due to the user needing to interact or the trust not being high enough for the request), then you bail out of the exchange grant and into one of the interactive grants instead to get the user to the front channel. Since you start in the back channel in XYZ, the client can send along any information that it has about the user right from the start, and the AS can determine what else it needs to do. This could include interacting with the user directly, or even building up a challenge-response for a user’s credential to be presented via the client and returned through a transaction continue message. On top of this, since we’re doing JSON in the back channel, we’ve got a lot more expressiveness for the data we’re sending back and forth beyond form-encoded strings. Non-authorization Interaction. This is one that Annabelle brought up in Montreal, and I’ll admit that it’s a bit further out than the others because it’s not even an authorization case. In this, an application tries to do something at an API but finds out that the user needs to interact with the service. This might be to consent, like in OAuth, but it also might be to enter an updated credit card. Basically, a backend system needs to say “Oh I thought things were fine but I need to talk to someone with a webpage right now”, much like the token-exchange-failure model in the last paragraph. This fits XYZ’s model of pinging the AS to try and do something, but having the AS optionally come back and say “hey get the user to this webpage, I need to talk to them”, with the main difference that it’s not inside a transaction request, per se. I think there’s something interesting happening here though that we should consider. Key Distribution. This is another one that lands us outside of what OAuth is used for, but not that far from its intent. If we have bound access tokens, that means the tokens themselves are bound to keys. Well, those keys could also be used in other non-access-token-based presentation mechanisms and protocols. Maybe the client needs to sign an assertion about itself, or a document, or a SET for audit purposes. In all of these cases, I think it can be argued that the access token represents here what the key can be used for, which might be in addition to its presentation at an API itself. I’ve been involved with plenty of systems that boil down to a key exchange or distribution problem, and when the trust is user-driven, it’s not that different from what we’re doing with tokens in XYZ. Structured Resources. Or in other words, “structured scopes” like Torsten is proposing. Again, I support this work for extending OAuth, but it’s got a lot of hurdles to overcome. For one, encoding the structures as form parameters is awkward, at best. Second, the combination of “plain” scopes with structured scopes would need to be carefully defined, since a “plain” scope can represent so many different aspects of the request. And finally, what goes into the structure is going to be a big issue of possible contention since not only are all APIs very different, so far APIs have used “scope” in very different ways. With XYZ, resource requests have a much more well-defined setup: they exist as objects describing the request, they’re combined with “AND” semantics, and they can be represented by strings that decode explicitly to the representational objects. I’d like to hear from others about what other use cases you’ve run into at the edges of OAuth (or related space) that don’t quite fit. I have reached out to the chairs and the AD to help determine next steps for XYZ within the IETF. I hope to be able to attend the Singapore meeting and continue the conversation in person there as well. — Justin _______________________________________________ OAuth mailing list OAuth(a)ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth

1 0

Agenda for UMA telecon 2019-09-05
by Eve Maler 04 Sep '19

04 Sep '19

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-09-05 Date and Time - *Thursdays 6am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2019- <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20> 08-08 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-08> - Status on UMA2 IETF I-Ds - Contributing to XYZ use cases - Nominations for chair and vice-chair - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from 2019-09-03 UMA business-legal framework telecon
by Eve Maler 03 Sep '19

03 Sep '19

https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 2019-09-03 Attending: Eve, Andi, Domenico, Lisa, Nancy, Peter, Tim, Colin Eve has put a new table in the Business Model Mapping Graphics deck <https://docs.google.com/presentation/d/1uigCMQI_TKuFyOstQTngYuZaqs36wwbE3BB…> for our perusal. We discussed ways to improve it, and moved around the arrows to make it more understandable and added use cases. We posed the question from a few weeks ago "For the care scenarios, do we need a primary carer/super admin type of role or are all entities in RRA equal?" It's not just for "care" scenarios. When a RRA/DS has the individual capacity to grant access to another (say) individual, then they are *not* equal, and access that can be granted can be taken away. If the two are truly equal in their rights (such as joint tenancy or a joint bank account), it's because there are institutional factors at play such as a law granting that equality. If it's because they are married and there's a law saying spouses have totally equal rights in a bank account, and they then get divorced, it's by law that the account access gets disentangled, not just by "access management technology". So if there were two RRAs (two married bank account holders, both DS's), and we went from state 2 to state 1 when then got divorced, it was because one of them is no longer going to be a DS in future and should no longer be an RRA in future. Presumably in this case it's not automatic but manual, and the parties need to tell the system what action to take (e.g. which party wants to remain in the system, when to take action, etc.). How complex should we get? In this new table, do we assume there's one DS? Recall that last time we discussed multi-DS scenarios and it rapidly became so complex we became uncertain about how to capture it. What are we documenting? The value is to be able to show proof as an ASO that the correct RRA is doing the sharing. Each "design pattern" represents perhaps many use cases in many different sectors. We posed the question from a few weeks ago "Federated authorization or not? Arguably, personas of a DS and a single DS have the same identity verification risk. If personas, then ”DS” in the state machine is replaced with “persona”. The key assumption: KYC works – if that fails, all the rest fails." See the new diagram in the Biz-Legal Mapping slides; any one resource owner/RRA is going to have a single login at an AS but could have a unique login at each RS that is federated with that AS. The single AS login could be strongly proofed, meaning that the ASO could prove strongly who that RRA is. Eve has moved our biz-legal meeting *a half-hour earlier* next week as she has a partial conflict. *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: UMA business-legal telecon TODAY at 8am PT
by Eve Maler 03 Sep '19

03 Sep '19

We haven’t held one in a little while. Let’s get back on track today. Details are on the calendar: https://kantarainitiative.org/confluence/display/uma/Calendar Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0