https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-19
MinutesRoll call
Quorum was NOT reached.
Approve minutes
- Approve minutes of UMA telecon 2021-06-10
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10>
, UMA telecon 2021-06-17
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-17>
, UMA telecon 2021-06-24
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-24>
, UMA telecon 2021-07-01
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-01>
, UMA telecon 2021-07-08
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-08>
, UMA telecon 2021-07-15
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-15>
, UMA telecon 2021-07-22
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-22>
, UMA telecon 2021-07-29
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-29>
, UMA telecon 2021-08-05
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-05>
, UMA telecon 2021-08-12
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-12>
Deferred
UMA in Wikipedia
Have started an open document with the current english content. Everyone is
welcome to suggest and edit and we can review next week
https://docs.google.com/document/d/1TbD4ODQOdQkLwHjlpjTQ4lbEPMbky67O8Clrzxe…
Relationship Manager - user stories
1. As a Client, I want to be able to declare types I understand, in
order to successfully use complex APIs
2. As an RS, I want to defer permission ticket creation, in order to a)
not have to understand the Client b) not make authZ decisions (tell me
don’t make me think)
3. As an ASO, I want to pre-register Clients, in order to assess their
appropriateness, capability and complete non-technical activities
4. As a Client, I want to pre-register with ASs, in order to a) test my
UX and technical integrations b) declare my capabilities
Minimal Interop Profile
Goal:
What parts of the spec will be test? Should we separate Grant from Fedz?
What is takes around the UMA AS
1. Mock RS (well known resources/scopes)
2. Mock Client (well known requests)
3. Mock IDP (well known RO/RqP)
Fedz:
- Mock RS test client
- PAT creation
- RS client credentials
- RO authorization → auth code flow
- 1 resource registration
- set of resources, scopes,
- 2 permission ticket creation
- 3 introspection
Grant:
- Mock Client test client
- Client Credentials → static/ well defined
- RPT endpoint
- claims pushing, multiple rounds of pushing?
- error
- claims pushing or gathering
- request submitted
- PCT
- claims gathering endpoint
Policy:
- RqP has the rights via identity
- Other requirements, agree to ad-hoc TOS
- specific acr/scopes in claims token from
FR AS:
https://github.com/ForgeRock/frdp-uma-resource-server/wiki
- claims pushing (IDToken)
- no
- PCT
- not quite
- request_submitted is supported, creates a pending req for RO, not
using ticket/interval though
- redirect_user / interactive claims gathering, gets a claims token
through an auth_code flow
IDENTOS AS:
- interactive claims gathering
- RSasRO, RO has client credentials with AS
- no
- request_submitted
- PCT
- claims pushing
*Discovery*
Per RS-directed
- the RO can tell the RS that some resources are public/discoverable
(their existence not their content...)
- RO is able to share that discovery URL to the RqP,
- doesn't mean the RqP can access all → could UMA protect
discovery/webfinger, and get back the specific "stuff" that RqP can access
- this is instead of sharing many specific URLs
- RO has abstracted URLs for specific resources, this is separate from
discovery?
File names... in medical case the resources don't have 'names', A LOT of
info falls under simple types. Eg sleep records vs infectious disease,
should the RqP be able to discover the existence of both types even if they
can only access the sleep records.
AS-directed (or discovery service-directed)
- An RqP goes to the AS and asks for all the resources granted to the RqP
- the AS has the resource and the policy about which RqPs can access
- can the RqP learn about the resource URLs (across many RSs) it can
access
- Similar to Pension Dashboard case, discover and register all pensions
with a single AS. RqP (user or financial advisor) go to the AS to find the
locations and authZ to access
- Identos use-case,
- the Client understands specific types of resources (eg xrays)
- send the RqP to the to the AS to
- i) know who the RqP is and (eg the Primary Care Physician)
- ii) which resources that RqP have that match the type (all their
patients xrays)
- iii) choose which of those to share with the client (a specific
patients for a specific encounter)
Two discovery endpoints
1. protected discovery → managed by AS
1. (or indapendant discovery service?)
2. OIDC distributed claims (endpoint, token) that the RP can get
claims from there
3. the AS doesn't know the endpoint in UMA today
2. public discovery → managed by RS
1. in FR impl, the RS proxies Client requests to the AS, to reduce
who the client needs to talk to and could provide the more wholesome
discovery
Attendees
As of October 26, 2020, quorum
<http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)
Voting:
1. Thomas
2. Alec
Non-voting participants:
1. George
2. Scott
Regrets:
1. Steve
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-05
MinutesRoll call
Quorum was NOT reached.
Approve minutes
- Approve minutes of UMA telecon 2021-06-10
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10>
, UMA telecon 2021-06-17
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-17>
, UMA telecon 2021-06-24
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-24>
, UMA telecon 2021-07-01
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-01>
, UMA telecon 2021-07-08
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-08>
, UMA telecon 2021-07-15
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-15>
, UMA telecon 2021-07-22
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-22>
, UMA telecon 2021-07-29
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-29>
Deferred
UMA in Wikipedia
https://fr.wikipedia.org/wiki/User-Managed_Accesshttps://en.wikipedia.org/wiki/User-Managed_Access
Anyone familiar to wikipedia to update content?
Can/should the group review and create some more accurate content?
- Alec to create a google doc with the current content for the group to
iterate on
Relationship Manager - user stories
2. As Alice, I want a way to grant Bob access to my resources without
knowing the URLs, in order to a) not deal with URLs b) share more complex
resources (ex not a PDF, a health record)
The RS registers a name and description at the AS, which is how Alice can
differentiate resources
In the FR impl, the RS after registering a resource, saves the resource id
(and other metadata), and *then* generates the URL. The URL is created
after registration, which is what Alice is meant to share with Bob. There
was also resource discovery at the RS, that would allow the RqP to query
based on specific other claims, this feature is turned on by the RO for
each resource. Part of the random URL strategy was to improve the privacy
of including information in the URL, instead of sharing
rs.com/georges_photos you can share rs.com/<uuid> without leaking
information.
The URI registration would allow RqP discovery of resources across RSs. If
we consider discovery as a layer ontop on UMA, we can separate the mappings
from the authorization path. The URL can change over time, the RS can
update the URL separate from any discovery needs.
The RS can also define the hierarchy of policy and groups many resources in
a single resource registration, ie taking 1000 or URLs and putting
registering a single resource.
When does an AS become as RS to expose a list of protected/available
resources? Doesn't necessarily need to be the AS, or can be a separate url
discovery service. Registration can be 1-n, not 1-1 eg many resources in
one registration. If there are public/private photos, then a request for a
public photo can include all public photo resource id, a request for a
private resource includes only the single resource id. The registered
resources could be 'public photos' and 'private photos'.
What is the UX of Alice managing her resources and policy? What is the UX
of Bob being granted access to resources? Where does sharing occur, from
the RS or AS?
The idea of a privacy wallet, people keep a record of their identity
relationships themselves. That ANCR record defines the PII controller and
contact info. Creates a privacy rights access point, in addition to the
policy. People can broadcast their services for discovery. This is done so
that on each new session the user can compare the privacy statement against
the previously agreed to one.
How does Bob reach out to Alice's resources in order to determine where to
go? Alice sends a receipt with her policy to Bob, including a URI to the
calendar (or to her Privacy Wallet?). If the URI is to his calendar, then
Bob can start an UMA flow. Bob would end up with receipts for Alice's AS
and her calendar service
Privacy aspects are internal to the AS today in UMA, or are implementation
specific. Alice shares a purpose, which must be mapped to authorization for
Bob. UMA isn't prescriptive about scopes, there can be a scope such as
'do_not_share' that tell Bob's client to not retransmit to 3rd parties.
However these scopes are legal by nature and not technically enforced. The
RqP/Client can need to push claims declaring their agreements (eg a
receipt) that include the PII controller who is taking custodianship of the
information granted to Bob.
Just as discovery is capability on top on UMA, the privacy framework can be
a profile on top of UMA. It provides implementation specifics where
end-user legal privacy controls are required. Could this use UMA resource
scopes sufficiently cover this? Or the claims pushing of a new claim_type
eg a ANCR receipt/rights claim?
https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#rfc.…
1. As Bob(RqP), I want to be able to discover resources available/shared
with me, in order to not need URLs sent by Alice
2. As a Client, I want to be able to declare types I understand, in
order to successfully use complex APIs
3. As an RS, I want to defer permission ticket creation, in order to a)
not have to understand the Client b) not make authZ decisions (tell me
don’t make me think)
4. As an ASO, I want to pre-register Clients, in order to assess their
appropriateness, capability and complete non-technical activities
5. As a Client, I want to pre-register with ASs, in order to a) test my
UX and technical integrations b) declare my capabilities
AOB
Attendees
As of October 26, 2020, quorum
<http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)
Voting:
1. Domenico
2. Alec
Non-voting participants:
1. George
2. Ian
3. Scott
Regrets:
1. Steve
I just noticed that there are five different language versions <https://fr.wikipedia.org/wiki/User-Managed_Access> of the User-Managed Access entry in Wikipedia. Neat. The page(s) could use some updates to reflect UMA 2.0, deployments of same, scenarios, new work, and so on. Anyone up for contributing a few edits?
Eve Maler | cell and Signal +1 425.345.6756
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-29
MinutesRoll call
Quorum was NOT reached.
Approve minutes
- Approve minutes of UMA telecon 2021-06-10
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10>
, UMA telecon 2021-06-17
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-17>
, UMA telecon 2021-06-24
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-24>
, UMA telecon 2021-07-01
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-01>
, UMA telecon 2021-07-08
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-08>
, UMA telecon 2021-07-15
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-15>
, UMA telecon 2021-07-22
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-22>
Deferred
Relationship Manager - user stories
1. As an ASO, I want to allow Alice to bring a resource management UX,
in order to not provide this myself
1. Today, the AS must provide some interface for Alice to see her
registered resources (uri) and the policy for each resource→RqP. Core UMA
has some implication that Alice can 'bring her own AS'
2. As discussed last time, Alice may need to work with many AS's, and
sometimes that is out of her control
3. A challenge may be that Alice needs to authenticate uniquely to
each AS? Alice will authenticate at an IDP, and there can be federation
4. IN RM draft
1. Instead of Alice managing resources in several AS UXs, she can
use her single RM to manage her resources. In some cases, the
existence of
multiple ASs can be hidden from her
2. The concept of the PAT is changed, such that a PAT represents
the entire RS (all ROs) and the resource negotiate between
the RS and AS
are the types, not specific resources
1. There's not necessarily a RO specific PAT, as the RS's API
may not support user context in the path, even if it does
there is a
challenge around getting RO specific uris to the RqP
2. ex an RS api `/me/profile` the RS get's a ticket that
represents that type of resource, and during claims
gathering the AS is
able to determine the specific profile to return to the
client. The RS
learns the specific profile either by inspecting the RPT or through
introspection
3. Some initial goals of RM were to make a 'zero knowledge' AS. An
AS that doesn't need to see end-user identity claims.
Identity federation
happens to the RM, the RM then registers RqP policy against
RS→RM resource
ids. The AS is only learning resource ids, and conveying to
the RS during
specific transaction. The RS is responsible to resolve the
resource id to
the right RO information
4. As there are more RS specified AS's, there are also new needs
for federation or mutual trust between those ASs to get back to widest
possible ecosystems. This is OOS of RM but could be achieved
through other
governance registries or discovery services
2. As Alice, I want a way to grant Bob access to my resources without
knowing the URLs, in order to a) not deal with URLs b) share more complex
resources (ex not a PDF, a health record)
1. Today, all of Alices resources are registered with the AS
independently, however this doesn't include any specific URI.
Therefore she
needs to get URIs for the RS, and somehow know which registered
resource id
corresponds to what URI(s). How does Alice know what at the AS means what
URI to the RS?
2. In some reference impls, the RS creates a new URI that is directly
linked to the registered resource.
3. rsurl.com/alice/A.pdf, rsurl.com/alice/B.pdf, rsurl.com/alice/C.pdf →
registered at the AS → (type:pdf, scope) x3 → (randomid1, randomid2,
randomid3).
1. the RS keeps track of relationship from public uri and internal
AS registered id. The RS writes RqP policy to the AS against
the randomidN.
2. This RS performs on RM behaviour instead of making Alice
interact with the AS at all
4. there are also challenges exposing URIs AT ALL to Alice and Bob,
if the URI includes any PI all parties can see it, even if they're not
authorized. Best Practice: NO URIs are human readable
5. Today this is somewhat addressed as URIs don't leave 'digital
space' we share them through copy/paste, not through analogue means
6. There are more challenge with URI sharing when the number of
resource is very large or are dynamically create (such as FHIR
observations created by a device)
7. Another FHIR complication is querying by time frame...
1. some ways to address through 'shortcut' scopes like
'last_three_month', 'not_before=<timestamp>'
2. This is better addressed by Rich Authorization Request. There
are still challenges with UMA async, Alice can't consider all possible
authorization requests ahead of time. Alice is smart but she
can't see the
future.
3. As Bob(RqP), I want to be able to discover resources
available/shared with me, in order to not need URLs sent by Alice
4. As a Client, I want to be able to declare types I understand, in
order to successfully use complex APIs
5. As an RS, I want to defer permission ticket creation, in order to a)
not have to understand the Client b) not make authZ decisions (tell me
don’t make me think)
6. As an ASO, I want to pre-register Clients, in order to assess their
appropriateness, capability and complete non-technical activities
7. As a Client, I want to pre-register with ASs, in order to a) test my
UX and technical integrations b) declare my capabilities
AOB
Attendees
As of October 26, 2020, quorum
<http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)
Voting:
1. Alec
2. Eve
Non-voting participants:
1. Scott
2. Zhen
Regrets:
1. Steve
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-29>
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-22
MinutesRoll call
Quorum was NOT reached.
Approve minutes
- Approve minutes of UMA telecon 2021-06-10
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10>
, UMA telecon 2021-06-17
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-17>
, UMA telecon 2021-06-24
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-24>
, UMA telecon 2021-07-01
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-01>
, UMA telecon 2021-07-08
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-08>
, UMA telecon 2021-07-15
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-15>
Deferred
Relationship Manager - user stories
Challenges:
- *Alice must know the RS exists*
- *The RS may not be able to trust ANY AS*
- The RS MUST provide UX for the user to receive URLs
- The AS MUST provide UX to establish policy
- Alice must collect and share resource URLs with Bob
- The Client must understand the type of the resource at the URL
- The RS must determine the acceptable scope for the client from a URL
- The AS may not be able to trust ANY Client
Which motive these stories:
Alice=RO, Bob=RqP, RM=Relationship Manager, RSO=Resource Server
Operator, ASO=authorization server owner
Medical Records has a complex joint-custodian/owner situation. Alice is the
subject of the record, however the RS has a responsibility to protect the
records. Today all EMRs do typically have authorization setup for internal
(ie staff) access to information. A separate UMA AS could be used to manage
patient access to their records to other consumer health applications. This
AS can be trusted by more than one EMR so that the health apps dont' have
to integrate with each EMR (and vice versa).
What does this mean for Bob, Hosp 1 trust ASa and ASb, and Hosp 2 trusts
ASb, ASc. Bob needs to understand which AS's can facilitate his access to
which Hospitals, and therefore may use different ASs.
1. As Alice(RO), I need a way to discover available RSs, in order to
learn about resources I own
1. Today in UMA, it 'assumed' that Alice i) knows of the RS, and the
the RS can expose ii) those URLs to Alice in some way
2. Is this analogous to the web without search engines? you have to
know explicit links to all your documents
3. There are two challenges, Knowing custodian of resources and
knowing the specific locations of those resources
4. In the RM draft,
1. it assumes that Alice knows the custodian. However the list of
custodians are registered either at the AS or with a
different registry
(discovery information for RM, can facilitate Dynamic Client
Registration,
eg RS trusts AS, so RS trusts RM) the relationship manager can
also be a conformance profile manager for the RS
2. the custodian tells Alice the specific urls of her resources
through the API
2. As an RSO, I need to trust a limited set of compliant ASs, in
order to meet my obligations to protect resources
1. Today, An RS is meant to trust any AS brought forward by a RO
(ByoAS) over that RO's resources
2. For a 'regulated' RS/custodian, it can't delegate authorization to
ANY AS.. The RS may have 1 AS that allows edit scopes, while it
may be more
open to patient read
3. In the RM draft
1. The RS doens't need to register every specific resource with an
AS, the specific resource information is conveyed to the RM
and then to the
AS. Instead the RS has a more general trust in the AS "I
trust you to issue
access tokens at all".
2. There are two bits of an RS given our a resource i) the access
token was issued by an AS it trusts ii) the access token conveys
information that was given the to the RM (the return trip to the RS
includes proof from the RO) (ALEC MAKE A PICTURE)
3. As Alice, I need a way to work with many ASs, in order to use ones
required by my RSs
1. Today in UMA, Alice works with her AS and brings it to each RS
that holds her resources. In a world where the RS restricts or sets the
available ASs, Alice has a greater need to work with more than one AS. If
Alice does work with multiple ASs, it's implied that each AS
offers it own
UX/authentication, this is not ideal for Alice.
2. In the RM draft,
1. a RM has an API with the AS, and can work with multiple ASs by
design
2. The RM is the RO nexus between RSs and ASs, which the AS is the
nexus between RSs and RPs (ALEC MAKE A PICTURE)
4. As an RSO, I want to allow Alice to bring a resource management
UX, in order to not provide this myself
1. Today, the RS must provide some interface for Alice to see her
available resources (uri) and which resource is registered at each AS
2. We're talking about the UXO=user experience owner
3. this might be a good place to put into use the blinding identity
taxonomy
https://docs.kantarainitiative.org/Blinding-Identity-Taxonomy-Report-Versio…
in relationship manager... it could check to see if these are
necessary and if possibly blinded..
4. In the RM,
1. *Alice has a single place to manage all her resource i) see all
available resources across all RS ii) see all registered
resources at which
ASs iii) manage policy of those registered resources at each AS*
5. As an ASO, I want to allow Alice to bring a resource management
UX, in order to not provide this myself
1. Today, the AS must provide some interface for Alice to see her
registered resources (uri) and the policy for each resource->RqP
6. As Alice, I want a way to grant Bob access to my resources without
knowing the URLs, in order to a) not deal with URLs b) share more complex
resources (ex not a PDF, a health record)
7. As Bob(RqP), I want to be able to discover resources available/shared
with me, in order to not need URLs sent by Alice
8. As a Client, I want to be able to declare types I understand, in
order to successfully use complex APIs
9. As an RS, I want to defer permission ticket creation, in order to a)
not have to understand the Client b) not make authZ decisions (tell me
don’t make me think)
10. As an ASO, I want to pre-register Clients, in order to assess their
appropriateness, capability and complete non-technical activities
11. As a Client, I want to pre-register with ASs, in order to a) test my
UX and technical integrations b) declare my capabilities
AOB
Sal touched up the ANCR notes from last week UMA telecon 2021-07-15
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-15>
Attendees
As of October 26, 2020, quorum
<http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)
Voting:
1. Steve
2. Alec
3. Sal
4. Andi
Non-voting participants:
1. Kay
2. Scott
Regrets:
