- WG-UMA - mailman.kantarainitiative.org

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 05 Sep '19

05 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

Reminder: business-legal framework telecon today
by Eve Maler 20 Aug '19

20 Aug '19

...at 8am PT. I’m under the weather and won’t be joining, but Colin will open the bridge for a “DIY” call for those interested to carry on, as discussed on the Skype chat. (Let me take this opportunity to remind y’all about the Skype chat if you’d like me to add you, and if you would like to get a proper invitation to the calendar entry, I can do that too.) Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Draft minutes of UMA telecon 2019-08-08
by Eve Maler 08 Aug '19

08 Aug '19

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-08 MinutesRoll call Quorum was reached. Approve minutes - - Approve minutes of UMA telecon 2019-06-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20> , 2019-08-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-01> MOTION: Approve minutes of UMA telecon 2019-06-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20> , 2019-08-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-01>. APPROVED by acclamation. Decision on UMA2 IETF I-Ds - The UMAGrant <https://tools.ietf.org/html/draft-maler-oauth-umagrant> spec and FedAuthz <https://tools.ietf.org/html/draft-maler-oauth-umafedauthz> I-Ds expire on August 17 if we don't take action - We can: 1. Let the specs expire and do nothing else beyond telling the OAuth WG chairs that we rescind our previous proposal (already done), or: 2. Decide to do an independent submission and go for an informational RFC instead, presumably in the Security Area - We were leaning towards #2, but we're still open at the moment. Please review the notes of UMA telecon 2019-06-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-06-20> to prepare to discuss this (it also links to older notes...) There's a third option Eve forgot to list: Do what we did before, and submit I-Ds that are "empty shells" of the specs that point to the real specs and just keep refreshing them. (Here were UMA Core <https://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/> and RSR <https://datatracker.ietf.org/doc/html/draft-hardjono-oauth-resource-reg-07>.) What we did with UMA1 was *not* keep refreshing them, because we started work on UMA2. We discussed the pros and cons listed in UMA telecon 2015-10-15 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-10-15>. If we're up front about wanting the spec to serve as an "archive", then they would presumably want to avoid breaking changes. Thomas related some past experience around cryptographic cipher standardization in the informational RFC process. Option 3 pros: - We are in control of the entire process. - The IETF drafts themselves contain little that goes out of date. Cons: - We have to keep taking action every six months. - The drafts don't themselves contain any technical substance of value. - The "marketing" value is perhaps minimal since there's no IETF "blessing" involved by anyone else. What is the process of independent submission? Here is information <https://www.rfc-editor.org/about/independent/>. RFC 4846 <https://tools.ietf.org/html/rfc4846> covers the process. This <https://www.ietf.org/standards/process/informational-vs-experimental/>explains why we want this to be informational. UMA2/XYZ use case work - See last week's notes <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-08-01> for a description of what's requested. - Use GitHub? The wiki? GDocs? Point of order: The XYZ work is not UMA! Current profiles and extensions that apply to UMA2 are very welcome to be submitted to the UMA WG for standardization. We know of several of them. Let's use GitHub and markdown for our XYZ use cases. Adrian has an idea for a use case but isn't sure about how to apply the template; we can discuss his use case on the list. These use cases could include things UMA2 solves now (e.g., all the things mentioned in the introductions to the two specs), and also things UMA2 *doesn't*solve now. Nominations for chair and vice-chair - You can see the leadership team list here <https://kantarainitiative.org/confluence/display/uma/Leadership+Team>. Reminder about this. Nominations are still open. FAQ revision - Our FAQ <http://tinyurl.com/umafaq> is extremely old and out of date Do we even need this document? Or should we revise it? Take a look and weigh in. The right spec link - Please keep linking to UMA Grant Recommendation <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html>. This will help search results point to the right file. 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. Eve 5. Mike 6. Cigdem Non-voting participants: - Adrian - George - Colin Regrets: - Nancy *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Happy 10th UMA anniversary!
by Mark Dobrinic 07 Aug '19

07 Aug '19

Hey Uma! My agenda says that today, August 6th, is the 10th anniversary of UMA, so congratulations to you all for all the care that has been given to get UMA to where it is since all those years! Mark

3 2

Notes from 2019-08-06 UMA business-legal telecon
by Eve Maler 06 Aug '19

06 Aug '19

2019-08-06 Attending: Eve, Adrian, Cigdem, Domenico, Lisa, Nancy, Sal, Thomas, Vlad, Tim, Colin Cigdem sent some thinking around the "multiple DS" cases: *Regarding multiple DS’es the table would look like this.* *The Multiple DS case may not occur often, but is present in the case of a shared bank account between partners.* *When a couple opens a bank account, they may start at State 5, when one of the couple goes under care, they transition to State 6,* *When one of them dies, the end state is State 1 if the other partner is the sole beneficiary, or if there is another person, it may go back to State 5, or State 7 etc.* *Not sure how to represent this technically – it seems to work for DS=2; not sure it extends to a larger number.* *Do we have cases where DS is greater than 2. * *DS>1 | Rep>0 | Carer>0 | State* * F | F | F | State 1: Self-management (Single DS)* * F | F | T | State 2: Management under care (Single DS)* * F | T | F | State 3: Co-management (Single DS)* * F | T | T | State 4: Co-management under care (Single DS)* * T | F | F | State 5: Self-management (Multiple DSes)* * T | F | T | State 6: Some/All DSes under care (Multiple DSes)* * T | T | F | State 7: Some/All DSes co-manage with Reps (Multiple DSes)* * T | T | T | State 8: Some or all DSes under care and co-managed (Multiple DSes)* If we're in State 5, but I decide to co-manage my bank account with another party, what does my partner get to say about the situation given that they are a DS too? What if the two partners have different accountants; does the second partner get to/have to consent to the first partner's sharing with a chosen accountant? Divorced parents may have different custody rights and agendas – but this may fall under the single-DS case. Joint bank accounts and DNA data seem to fall under the "multiple-DS" case. What use cases are truly realistic around the RRA and sharing breakdowns beyond that? If there are whole state machine branches that are truly not realistic, let's not map them. Are trusts another example of potentially multi-DS and multi-RRA? It seems so. Trusts generally are for administering physical assets, but if they could be used for virtual assets as well, then what we're doing here could provide real added value. The ASO/AS role provides value in terms of the actual permissions as they change. Right now we're focusing on the RRA/RO role changes, which are at the "head" of UMA-technical. Is there another service/party needed, something like a "relationship manager", to manage the state transition stuff? In identity management, there are some solutions that do things like this under the heading of identity lifecycle management, relationship management, and essentially "multi-identity lifecycle management". Thinking out loud: Three siblings open a shared account, A, B, and C. They appoint an account manager, D, as an RRA. So each is in state 6. Brother B decides he wants to self-manage the account, so he may need to get permission from the others before transitioning to state 1. Sal and Mark at OpenConsent have been doing some work on policy states and state transitions; we will hope for a demonstration soon. We think it's complementary. Some concrete scenarios: This PC Magazine article <https://www.pcmag.com/article/331910/how-to-delete-your-facebook-account> explains a) how to delete your Facebook account, and also b) how to request removal of accounts for someone who is medically incapacitated and c) how to get an account memorialized when someone dies. The latter two seem RUFADAA-like and have very close analogues in our Cradle to Grave use cases. For example, in use case (b), the party making the request has to prove they have the right to be the RRA (a Rep). In use case (c), the RRA role is self-asserted but they have to prove the DS has died. Should we think of multiple state machines, one for every DS, and not maintain States 5-8 as formal constructs? Does the "relationship manager" center on resources first (e.g. the bank account) and then look up the relevant current DS(es) and RRA(s)? Relationships tend to be graph-like, without a single "head of the hierarchy" in reality, even if the RM isn't using graphDB technology to manage them. There are two *mechanisms* of state transition (not reason, but mechanism) we might tend to see: either automatic or manual. Automatic means that you don't need consent or any other active participation by parties for the transition to occur. It times in (little Johnny grows up(, or a law now goes into effect, or a sensor reports a high enough temperature, or whatever. You might, however, need notification and other workflows. Manual is when parties do need to take action, such as consent or permission or setup (such as registration). Applications could need custom workflows in either case. Next steps: Apply the three FB use cases and Nancy's healthcare use cases to UMA and our state machine and try to make them "work" visually and in writing. *We don't have a formal meeting next week.* Cigdem will inform whether she can hold an ad hoc meeting at either our regular time or another time. We do have a meeting on *Aug 20*. *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from 2019-07-30 UMA business-legal telecon
by Eve Maler 06 Aug '19

06 Aug '19

(Sorry for the delay! Hmm, the table contents don't seem to be showing here, so please follow the link to see them.) https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 2019-07-30 Attending: Eve, Andi, Cigdem, Nancy, Vladimir Prihodko (works at Lush Group, has implemented UMA1 there), Domenico, Colin, Tim; regrets from Lisa We examined the outputs of the ad hoc meeting of last week (in slides <https://kantarainitiative.org/confluence/download/attachments/77300164/UMA_…> form). The use cases drive the state machine. So you enter it at whatever point depending on the real-world circumstances. There's a question about which system you're interacting with in each use case. E.g., an employee system is an RS that holds hours worked, paid time off, etc., and personal data management is divided up between RS's. We may have to try this with use cases from different industries and see how it comes out. But presumably any single "run" of the UMA protocol only involves a single cohesive system that interoperates. If you're operating at the technical layer, by definition it sort of all "works out" because the protocol defines how things work, but at the policy layer, questions creep in: having multiple ROs (RRAs) is like science fiction (the multiple-worlds hypothesis [image: (smile)] ). If multiple RRAs can set policy, does one's policy override another's, or do they combine, or do they get "shares" in the policy in aggregate, or what? These could all be different use cases. We know of some common ones, like where the parents (or set of guardians) for a child have to all agree to release the medical records of a child. But we don't have to figure out how to implement this, just acknowledge that ASOs need to be free to meet the needs of their users. We could leverage a table as well for describing the states. That might be a useful way to discuss those two factors in common for a lot of the scenarios. We're not sure if there is a third dimension. Could any one resource have RRAs that have to "split" along these lines? E.g., *Joe* and *Jane* have a joint bank account. *Joe* is competent to self-manage it, but *Jane* becomes ill and wants to designate a third party, not *Joe* but her attorney *Jim*, to manage the account for her. And *then* something happens to *Jim*... It's delegation turtles all the way down. How realistic are some of these? There are legal constraints on continuing to add further and further delegates. But at some level, US laws such as RUFADAA (which is more widely adopted than ever – later Tim provided adoption status in email <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/vDl5Q3czO…>) could provide a basis for at least the first layer – or maybe as far as two layers? – of delegation to be handled at a "policy layer expressed by technical means" with UMA's help. Is "policy layer" the right name? The overall generic name has been "business-legal" but that may be too awkward. Let's continue this topic. Would it be possible to define the policies themselves to make them interoperable? To be discussed. Questions we still need to discuss as outlined in the slides: For the care scenarios, do we need a primary carer/super admin type of role or are all entities in RRA equal? 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. *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Reminder: UMA business-legal telecon tomorrow
by Eve Maler 06 Aug '19

06 Aug '19

We meet 8am 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…>. Trying to access this link will send me a notification to share it with you with your preferred ID, if I haven't already given you access. Agenda items: - Continuing to answer the state machine questions collected during the ad hoc meeting two weeks ago (see last week's notes and the linked slides) - Seeing if we can apply the state machine model to the requesting side in similar fashion to the RRA/RO side *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0