Minutes

Roll call

Quorum was reached.

Approve minutes

• Approve minutes of UMA telecon 2018-10-18 and UMA telecon 2018-11-02

APPROVED.

Discuss extensions added to implementations or desired in more depth

Slide 2:

Alec presented on what Identos is doing to profile and extend UMA. They are presenting an UMA-standard interface to clients while maintaining RO privacy. They made most changes on the RO side. The stuff in blue is their additions. The biggest privacy challenge was the AS's ability to correlate transactions/interactions. The biggest change is the addition of the Agent role. The Agent is permitted to maintain secrets and private information. They're working with the University of Ottawa.

Client requests are all delegated to the Agent. The moved the RS relationship to the Agent from the AS. The client can get resources from many different RS's.

The last change has to do with being an IdP ( ? ), since the AS is decoupled.

Slide 3 (Demo 1): Registration to Health Network. This is a test with the Ministry of Health in Ontario. The AS is the Ontario Health Network. Niagara Health is a hospital in Ontario that has a relationship with the RO. (We viewed the createID.mov demo video, showing the steps on the slide.)

Slide 4 (Demo 2): This follows the UMA flow as far as the client is concerned, except that it skips the permission ticket request and goes directly to claims gathering (step 1a). (We viewed ton-demo.mov.) The claim the RqP is using is a FIDO-authenticated. PATs don't really look the same because it's between the RS and Agent.

Scopes are predefined so the client goes to the AS first and asks for the scopes it's preconfigured to ask for. The "federated authorization" piece has been sort of replaced. The client starts by presenting a "capability ticket" rather than a variable-meaning "permission ticket". The PAT sort of, analoguously, "moves to" the client side. This is what the blue "P" means on slide 2.

There is "RS discovery" instead of AS discovery. There is still a previous relationship with RS's. Immunization records, for example, might come from one or another source. The RO can say which RS should be used to fulfill a request.

They have been looking at there being multiple AS's in the environment, potentially in a cross-border use case. The Agent role could involve SSI ("wallet" apps) with consensus-based trust with different AS's. So far SSI is an option that they're investigating.

They have a draft extension spec that they've been working on for 1.5 years. Sharing that would be welcome, as that helps interop. With lots of startups out there going so fast, it was noted, consumers and security can suffer without documenting a pattern being used. They are wrapping their project with Ontario around the end of this month and think they can share their draft after that.

IETF and the UMA specs

Eve forwarded a link to discussion about AS discovery mechanisms on the OAuth list that is UMA-relevant. IETF is generally mostly F2F-friendly and has three (really big) meetings a year. March 2019 is in Prague and July 2019 is in Montreal. Thomas speaks up about attending Europe and North America meetings to advocate for UMA design patterns and themes. Adrian and Eve as well. Nancy speaks in favor of getting UMA better understood in the FHIR community. There is a FHIR event in Amsterdam next week. 

180 degrees use case / decoupled use case discussion

tbs

Attendees

As of 18 Oct 2018, quorum is 5 of 8. (Domenico, Peter, Sal, Andi, Maciej, Eve, Mike, Cigdem)

1. Domenico
2. Sal
3. Peter
4. Maciej
5. Eve
6. Cigdem

Non-voting participants:

• Adrian
• Alec
• Nancy
• David
• Scott
• Thomas
• Colin

Regrets:

• Tim
• George
• Mike by reason of tubas
• Andi by reason of sound systems