https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-06
MinutesRoll call
Quorum was reached.
Approve minutes
- Approve minutes of UMA telecon 2021-04-22
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22>
, UMA telecon 2021-04-29
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-29>
Deferred
Pension Dashboard Update
https://kantarainitiative.org/uma-profile-for-uk-pensions-dashboard-program…
Kantara is waiting to make a press release on this topic. Next steps, reach
out and get latest versions of profile + design docs from PDP
This program has started to generate some new inbound requests/question
about UMA! Asking about US implementation/deployments. Focus was
financial/enterprise use-cases, not health care. UMA profile of FAPI anyone?
The topic of UMA + <other standard> continues to come up. (UMA +
Openbanking, UMA + UDAP, UMA + SSI).
There has some *very early* interest for Kantara (and Direct Trust, EHNAC,
SafeIdentity) to assess + certify UDAP solutions.
This re-raises the idea to create a UMA certification process/program.
Implementors Page
Please feel free to update your entry with any developments or deployments! UMA
Implementations
<https://kantarainitiative.org/confluence/display/uma/UMA+Implementations>
IIW Review and Thoughts
There is a lot of different communities and group to follow, all working on
very similar (but different!) technology stacks, and very few in true
production (beyond pilots).
On the Good Health Pass front, there has been some 'softening' of the SSI
positioning such that it will also interop and trust x509 based
certifications, not only DID registries. The use of certs + cert chains is
exactly the technology used in the passports + their chips. mDL is also
using x509/certs and achieving the same outcome of distributed trust.
Single root (Root CA vs DID registry) that has distributed authority
through (certification vs VCs). A major challenge is the ability of
technology to be live & deployed, by the time tech solutions are available,
the need has changed (contact tracing → testing → vaccines).
EU green cards or physical vaccination receipts will be the most ubiquitous
way to demonstrate vaccination. For US Citizens re-entering US, the
solution today is that the airline MUST ask for vaccination, and the
traveller MUST answer accurately. No test result or quarantine
requirements. The liability is on the traveller to answer accurately.
Profiles Discussion, relationship manager draft
Identos has started to implement parts of this profile, will have some api
specs to share from this effort. Still looking to find some overlap with
SSI and VC issuance, e.g. through
https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ . Through
the impl, will not implement any of the authorization server management
api, instead focus on the RS declaring available resources and letting
Alice capture those resources as 'credentials', such that proof of
ownership can be including the RPT/introspection. Giving the RS a mechanism
to verify not only Alice's relationship to the AS, but also Alice's
explicit approval of the RPT issuance.
AOB
Attendees
As of October 26, 2020, quorum
<http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 8. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)
Voting:
1. Michael
2. Peter
3. Alec
4. Domenico
5. Eve
Non-voting participants:
1. Nancy
2. Colin
Regrets:
1. Ken
2. Ian
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-06>
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-29
MinutesRoll call
Quorum was NOT reached.
Approve minutes
- Approve minutes of UMA telecon 2021-04-22
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22>
Deferred
Pension Dashboard Update
Under resources, the PDP profile and license are up. There will be some
fine tuning over the coming days
https://kantarainitiative.org/uma-profile-for-uk-pensions-dashboard-program…
IIW Review and Thoughts
Huge focus on DIDs and SSI. They're is a lot of ssi community discussion to
move past the issues as they arise eg the growing number of DID methods.
Discussions are starting to move up the stack towards the user.
OAuth focused solutions are being used in practice to solve real-world
problems. Helps to explain why there is less discussion on these topic vs
DID/SSI. There seem to be some other forums for ietf/oauth vs at IIW.
The focus on mobile apps will hinder the SSI, there is some new efforts to
standardize HTTP based API, a lot of current projects use web based keys
systems (did:web & did:peer).
The focus on wallet/user controlled software is good from privacy
perspective, but pushes a lot of liability to the user. The chain of
trusted systems is broken if wallets aren't assured as part of this chain
(from issues→verifier, or OP→RP).
The discussion is very low building block levels around the control of
identifiers. There is a shift from blockchain only solution to more witness
based key rotation/control (KERI).
At TOIP, Mark has been working on a privacy controller credentials to
define how parties who receive information must give the user a record of
having their data(?). The 'accountable person' from a gdpr perspective is
often not the subject/company, but some other party eg a lawyer/law firm.
Interesting to see if browser vendors start to pay attention if they can
put wallets in the browser. This would seriously improve adoption and make
it *easy* for people. Sal notes there is a push to this, trying to make it
a clear request. Firefox has a concept of 'personas' ~5years ago. The DHS
SVIP was based around a browser extensions functionality (CHAPI). Microsoft
has all the pieces to do this (vested interests in DID, and they own a
browser). For privacy, browsers have been pushing against tracking + RP
collusions (eg restrictions on third party cookies.) We need notice +
transparency before transactions occur, similar to how OAuth works today
(show notice and user has choice before sharing). A lot of current high
assurance requirements mean browsers cannot see any of the credentials/PII,
and increase the *desired* collusion between parties (everyone is well
well known)
Reliance on Browsers/mobile OS risk "centralizing" or restricting the
options, against the agency principles of SSI. Receipts can remove
dependencies and provide interop between wallets. There are ways to use a
receipt to show provenance to get a new credential issued. In this context
a receipt isa credential, it can be a VC if it needs some of those
functions. How do zero knowledge proofs affect these discussions, change
the surveillance possible. ZKP is part of the challenges with the many DID
methods, the DID methods tends to define ZKP functionality of
identifiers/keys which changes/removes the interoperability of the VC
objects. ZKP needs to be understood by the verifier
Are notice specifications a type of data provenance for a VC?
Data provenance - when was it collected, constraints, purpose of use...
Data sharing is system to system, however notice is inherently something
for a human person. Today, user/person has little ability to assert the use
of their data, this is something that must be added/built into a platform.
A notice resulting in a receipt allows a person to communicate with the
data controller and assert their rights as agreed upon. A physical receipt
establishes the trust that the merchant won't take more than the printed
amount.
Want to separate rights from services, people need support manage their
identities and private keys, and that's why account services exist.
The decentralized goal is somewhat of a red-herring, the vast majority of
people want and need support to manage this technology. There will be some
people (eg cryptocurrency community) however if this technology is entirely
hidden, it ends up being a different technical mechanism for providers to
hide from the person. If there is some transparency/portability out of the
box maybe this is the person value, however this hasn't been demonstrated,
it's the same as an with current web technologies, there needs to be
integration/testing between the domains.
The issues/holder/verify split is logical, in practice all parities end up
performs all three roles. This requires additional definition of
responsibility/accountability in an ecosystem. OAuth has a clear
delineation in this case (OP< RS< RP <RO)
Profiles Discussion, relationship manager draftAOB
ANCR workshop around adding standard notice/policies, adding governance to
open source projects. Goal to drive to interoperable policies
https://github.com/Open-Notice/ANCR-Hack-Worshop-May4th-2021/blob/main/READ…
Attendees
As of October 26, 2020, quorum
<http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 8. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)
Voting:
1. Michael
2. Thomas
3. Alec
4. Sal
Non-voting participants:
1. George
2. Colin
3. Nancy
4. Scott
5. Mark
Regrets:
1. Domenico
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22
MinutesRoll call
Quorum was reached.
Approve minutes
- Approve minutes of UMA telecon 2021-03-18
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-03-18>
, UMA telecon 2021-03-25
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-03-25>
, UMA telecon 2021-04-01
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-01>
, UMA telecon 2021-04-08
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-08>
, UMA telecon 2021-04-15
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-15>
Eve moves to approve. Peter seconds. Motion Passes!
Pension Dashboard Update
RFP is released, included profile + design doc largely the same as what
we've reviewed previously
Still finalizing the Kantara hosted publication of the contributed profiles
(outside the UMA WG). We'll update the UMA site with some explanation after
it's up
Kantara will look to put a press release out when the documents are posted
Is there interest in implementing/trying the profiles from the WG members?
Origo has an (older) POC of the AS/system. IDENTOS is interested in
building a conforming 'RS Adapter'. Could we try with some open source UMA
components (gluu gateway/keycloak)? Members will need access to the RFP
versions of the profile + design documents
Identiverse 2021
We can have a dedicated UMA presentation slot (25mins)
Alec will ask about attending identiverse, volunteer to present (maybe
remote). Presentation *can* be recorded or live
Andi will cover the UMA EIC presentation in Sept
IIW Review
Eve and George presented the UMA 101 session with 15-20 attendees. Took a
slightly different approach, more of a true 101 session with increasing
detail as it went. Covered new profiles and the UMA<>decentralized identity
relationships. Eve can upload the new slides to the wiki
Some questions about user interface standards "will there be standards
about UMA interfaces?"
Ian notes that Pension Dashboard → Dashboard client sharing of pensions
resources is possible in the profile. The person dashboard is a true
interoperable uma client. After finding, Alice can access her pensions from
any Dashboard client after registration.
Pensions dashboard includes an idea of Alice→Alice sharing happening before
any Alice→Advisor(Bob) sharing happens. Eve notes this pattern is useful in
health care use-cases where the Patient ID works against some privacy
goals, anyone with the ID could see/access a lot with a FHIR API
The idea that UMA is a layer above any identity let's UMA apply very
widely. However, specific deployments do need to specific the identity
trust model (where is it integrated, who has to trust it, etc)
The PDP profile is a lot of specifying the identities, which ones exist
(Alice as Citizen, Bob as Advisor), where (at AS and Dashboard), whether
they need to be conveyed between system (IDToken to RS for matching), how
they are stored + resumed (PCT profiling). FPX also specifies identifies,
no IDs at the AS, used mainly at the RS, the Wallet needs authentication
and may rely on the RS for ID.
Looking for production DID/VC use cases? NHS Truu id? A lot of challenges
being raised about wallet interop, the growing number of did methods,
technical limitation of DID-SIOP and the lack of direct interop with
existing Identity/Authorization systems. A lot of people questioning the
market/use-case/user drivers for SSI, there are solid example in peer dids,
but not clear overarching path forward.
Profiles Discussion, relationship manager draftAOBAttendees
As of October 26, 2020, quorum
<http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 8. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)
Voting:
1. Michael
2. Eve
3. Alec
4. Domenico
5. Peter
Non-voting participants:
1. Ian
2. Colin
3. Ken
Regrets:
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22>
Best,
- Alec
