https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-08
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>
Deferred
Relationship Manager - user stories
Review the Diagram:
https://groups.google.com/g/kantara-initiative-uma-wg/c/WAnizgl08Fg/m/YjflL…
Discussion Recording (split into 4 parts)
2021-05-20 13.24 UMA Working Group Part 1.mp4
<https://kantarainitiative.org/confluence/download/attachments/147488962/202…>
2021-05-20 13.24 UMA Working Group Part 2.mp4
<https://kantarainitiative.org/confluence/download/attachments/147488962/202…>
2021-05-20 13.24 UMA Working Group Part 3.mp4
<https://kantarainitiative.org/confluence/download/attachments/147488962/202…>
2021-05-20 13.24 UMA Working Group Part 4.mp4
<https://kantarainitiative.org/confluence/download/attachments/147488962/202…>
Here's a token and here's where to go: OIDC distributed claims. Existing
mechanism to pair and endpoint with a token
Want to be able to still share a URL and have flow work. This is a
discovery mechanism, has many privacy implications, eg user understanding
what the policy means. How does the user really know what will happen, do
we need a notification mechnism to allow review ahead of the disclosure? We
don't nessicarily want it to be a revocation after the data is shared. In
this case the consent needs to be just in time, eg Alice is notified about
the specific request based on the more general policy. This is back to the
CIBA/liberty alliance interaction service, where the the AS can reach out
to the RO. One the client side this is handled by the request_submitted
token response.
How would discovery be layed on top of the existing protocol (vs overload).
Discovery creates AS-first (or discovery server-first) flows
- exposing the UMA Fedz resource API to the client
- two step process, the client/RqP are first identified to the AS, to
get access to an AS hosted resource API
- A discovery endpoint, the client goes there first and then gets a
ticket to use with a token endpoint
- who hosts discovery endpoint? can is cross AS's, it is discovery
only for the UMA protected URL, where each URL can be independantly
protected.
- pass in the resource id (eg resource indicators) to the token
endpoint with a PCT
We are separating discovery from existing UMA flow/roles, it can be
co-located with an AS or entire separate service, in future could be
colocated with RM (Alice shares he RM url instead of specific URLS)
In UMA, I pick an AS, all of my/Bob's services go through my AS to get
authZ to my resources. Reality has shown there are likely 3/4 different
ASs → this is one purpose of the RM, to be a layer that serves Alice
directly. Comes down to where agreegation happens, and who knows about it,
how this makes Alice's life easier to manage her distributed information.
We are seperating the policy of discoverability from the authorization to
access, they have different policy needs. If these are different, why allow
discovery? Because Alice wants transparency and want to understand the
different risks. Knowing that Alice takes landscape photos may be
discovery, while access to specific photos may want to be controlled. This
goes back to a general policy around discvoery (all photographers can
discover) vs the specific RqP (only selected photographers can access
specific photos, tiered access)
Discoverability works well where there are a small amount of URLs, however
in complicated APIS, there could be 100+. There can be expansion to
'wildcard' urls or types of resources vs the specific URI.
RS first access lacks mechanisms for intent. The RS must extrapolate from a
single request the scope of resources to includes in the permission ticket.
Discovery allows client/RqP to speak to there intent, eg as a client I can
understand only specific resource types, however the RS can't know this
ahead of time. We want to match the granted resources to the
intent/capability of the Client. Bob can show up and declare what privacy
obligations he'll uphold, and leave the notarized receipt with the AS for
Alice to follow up with eg Data Controller information. Rather than audit
trail, the receipt is meant to be one-time signal that be compared over
time and allows the identification of policy change. On all resource
accesses the AS receives a new and comparable-to-previous receipt.
I'm a health care system or photo sharing systems, the site needs to
standalone. The could be cases where an RS is trying to add authz
capabilities, this can be delegated to the UMA environment without major
changes to the core RS. UMA needs to work for both scenarios.
*The interesting questions always comes back to liability, if the AS is the
authority and the RS releases the wrong data, the AS still needs to take
the liability. *The RS is the data custodian, and they always have
liabity/responsibility to the RO. If company A uses UMA as technology for
RS/AS/RM/Discovery, then there is little liability question, it's all in
the same place. Once the ecosystem is wider, where company A holds the
data, and delegates authZ to an AS of company B, now the liability split is
less clear.
When PDP did the dashboard, there is an idea of consent boundaries.
Anything happening at the RP on behalf of the RO, has a separate consent
boundary, between teh client software and the RqP.
The ANCR would allow Bob/Client to create the notice receipt to the
discovery mechnism so that Alice is able to see what terms we're accepted.
>From RqP perspective, access is based on presented claims, to meet Alice's
policy. Bob wants to set his terms for sharing those claims with an AS(?)
The policy within the AS is not-specified, the ANCR could be a profiled
claim type for Alice/Bob to both understand the legal
requirements/expectations for the claim handling. Purpose is to reduce the
cognitive load on Alice/Bob to understand the terms, having a common
vocabulary vs ad-hoc TOSs.
As an RqP, I can define an ANCR receipt, in order to specific my
requirements for claims handling. THis could be a claims presentation to
the AS. There are two privacy rights that need to be balanced:
Alice→arbitrary client vs Bob→arbitrary AS. In ANCR, there is a cyber
rights notary, when Bob wants access he see's Alice's preestablished
policy.
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. Thomas
2. Alec
3. Domenico
4. Sal
Non-voting participants:
1. George
2. Ian
Regrets:
1. Eve
2. Nancy
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-08>
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-01
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>
Deferred
Relationship Manager - user stories
As RqP Bob(reserach), I want to be able to request access to a set of
Alice's resources (heath information) directly from Alice's AS without
knowledge of their location(health record repositories), because I don't
have to bother getting or caring about all the locations from Alice first
(since there is no direct relationship between Alice and the researcher)
A reseacher may discover health records that have been authorized for them
to access, without needing a direct relationship with the RO. In this case,
Alice can mark her resources at the AS as being approved for someone with a
specific claim. THis isn't a specific consent, ie to a specific RqP,
instead she's specifying the claims that the RqP must present (such as a
particular study, or researchers from specific IDPS). How she knows which
avaialble studies/research institutes would have to be part of the trust
ecosystem known to the AS. The AS can define the size of this ecosystem.
The rule at the AS *"I Alice allow people with claim=researcher from
idp=[baylor, acme] to access these specific health resources=[A@RS1, B@RS2,
Immz@RS2]"*. This next component of this is how that Client/RqP can
understand the scheme/type of the resource being accessed. The Client
should be requesting and receiving resources that are useful to it and not
other ones (data minimization).
This reflects the "three layers or interop", ecosystem, protocol, schema.
If 3/3 aren't there things don't work...
How granular can these rules be (resource type, specific resource, resource
+ scopes) be? , "my health record = patient/*.*" "read my heath record
*.read" FHIR has some ability to be queried in graph-y ways, however
usually it's very scope based. in SMARTonFHIR, the whole RS is the Resource
and you specific scopes for specific "patient.read oberervation.read ..."
then you can further apply confidentiality (conf/*) or sensitivity scopes
(sens/*), however those apply to the entire set of scopes.
In genetic disease, the gene has a list of many mutations that could be
queries, relevant to specific conditions. Or the entire gene, or types of
how that gene is captures (microarray, single cell experiment). ANother
example where the client/RqPs ability to understand and use the data should
be assessed before giving access to the data. They might only need to know
if there is a specific mutation, not the whole sequence. Or a set of genes
relevant to breast cancer. There is a need to understand the purpose before
giving more holistic information, it depends on the person who is
investigating
Is the gene the resource? Resource=(gene), scopes=(diseaseA, diseaseB,
phenotypeD, specific-featureC, single-cell-experiment). The client/rqp can
be filtered against the avaialbe gene resources based on those scopes.
There are vocabularies that are standardized through industry that would
help create this language to drive interoperability (the schema level
interop)
What audit capabilities would Alice have to see who/what institutes
actually access her information? The AS should be able to provide this, and
the RS would be able to provide even more specificity. Alice must be able
to understand up front what level of audit she will receive. There is a
dichomoty of behaviour a) people who wont' check and b) people who will and
take action on this information. *ANCR intersection,* when the CLient is
granted access lodge a consent receipt for Alice's records? This CR can be
pushed as a claim (json) for Alice to understand how the Client will treat
her data, who to contact etc
Alice is delegating some interrogation of Clients to the AS, the blanket
consent statement can't consider all Client terms (since Alice isnt'
present at that time),
There is a need for Bob to know the AS at which to request access from
As RqP Bob(financial advisor), I want to be able to request access to a set
of Alice's resources (pension information) directly from Alice's AS without
knowledge of their location(specific pension providers), because I don't
have to bother getting or caring about all the locations from Alice first
(since this is cumbersome to Alice and the Advisor)
The rule at the AS *"I Alice allow people with claim=advisor,
myadvisor(a)advisingcompany.com <myadvisor(a)advisingcompany.com> from
idp=[advisor idp] to access these specific pension resources=[A@PP1,
B@PP2]"*. The resources available in this rule are the registered resources
from an earlier discovery/registration step (both cases). This also allwos
the RS to not guess what resources and scopes the Client needs based on the
inititial request with the URL (RPT-less request), the AS has a much
clearer idea about the Clients capability and what specificifally has been
granted after claims gathering has occured.
Reviewing the Diagram:
https://groups.google.com/g/kantara-initiative-uma-wg/c/WAnizgl08Fg/m/YjflL…
Is there an alternative where Alice tells the AS, my resources are here
(RS)? This could be the AS as RelationshipManageer, where the RM reaches
out to the RS to read the available resources. The challenges is still in
PAT establishment.
Could Alice create policy before resources are registered? This is getting
closer to delegation/consent vs protocol level
UMA Interop Testing
Deferred
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. Peter
2. Alec
3. Domenico
Non-voting participants:
1. Zhen
2. Ian
3. Scott
Regrets:
1. Steve
Hi, as requested have collected the user stories we've looked at around the
Wallet/ Relationship Manager drafts for discussion tomorrow
From:
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-11-19
As RqP Bob, I want to be able to request access to a set of Alice's
resources directly from Alice's AS without knowledge of their location,
because I don't have to bother getting or caring about all the locations
from Alice first.
As client C used by RqP Bob, want to be able to request access to a set of
Alice's resources directly from Alice's AS on Bob's behalf without
knowledge of their location, because I don't have to retrieve the locations
first.
—
From:
https://groups.google.com/g/kantara-initiative-uma-wg/c/f0g98sr22Rw/m/M5jK9…
As a RO, I want to manage my resources independently of each individual RS
(UMA core prop)
As an AS, I want to decouple the consent management UX from the
authorization services,
As a RO, I need a personally controlled user-agent (UMA Wallet) to manage
my key material, in order to maintain personal-agency in ecosystems
As a RO, I want to authorize a "UMA Wallet" to manage RS resources, so that
I have a single view into my available RS's and Resources
As a RS, I need Alice to authenticate in order to determine which resources
she can manage, in order to ensure appropriate management access
As a RS, I need Alice to establish credentials (pub key), so that I can
trust externally asserted policy was issued with Alice
AS a RS, I need to trust delegations signed by Alice's key, so that Alice
can allow Bob (other keys...) or <<claims gathering condition>> to access
her resources
As a RS, I may delegate resource management user experience, so that I can
focus of my core service to the RO
As an RS, I need to know which AS(s) Alice wants to use, in order to
delegate access control (uma core)
As an AS, I want to delegate RqP identification to a UMA Wallet, so that
- a RqP can choose their private key and consent management provider
- I can avoid directly holding or seeing a users personal details
Best,
- Alec
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-24
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>
Deferred
Relationship Manager - user stories
From:
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-11-19
As RqP Bob, I want to be able to request access to a set of Alice's
resources directly from Alice's AS without knowledge of their location,
because I don't have to bother getting or caring about all the locations
from Alice first.
- this one was more related to resource definitions - not resource
manager
- Alice can give discovery handle (uri to resource), or since Alice's
stuff may be in many places, Bob can discover all of the location's by
Alice only sharing the AS (as the discover function)
- SAML 1.0 only have IDP initiated SSO, then expanded to other use-cases
eg SP initiated SSO. UMA so far has deferred discovery, however this brings
it back into the scope
- it's not hard to be told which RS, eg registered the resource_location
with the resource
- there are potential security/privacy concerns with this approach
- Is the client request bounded to a specific RO from the offset.
- Client says to AS, "im looking for these types of resources
(types/definitions/indicators) with these scopes" ie by using a UMA Fedz
Permission endpoint exposed to the Client
- AS returns a UMA ticket and can continue through UMA grant
(pushed/interactive claims)
- What granularity is the Client/RqP making this initial request for
resources? Over resource descriptions: resource type + scopes
- *There are major implications for the token response to the Client:
token_type, multiple access tokens, including the resource_location + type*
- Previously only one Resource Server is ever granted (maybe over
many specific resources), however this requires only 1 token
- want to maintain the resource server constrained access tokens
- another option is we token response in maintained, and the client
makes multiple token requests (eg with the PCT) and the specific resource
type/indicator
- PCT fits within current UMA model since the PCT allows the
client to get new access tokens for other RSs without having
to go through
claims gathering again
- This may also enable the RS to register as a resource type
provider, is there a way that no specific resources need to be registered
at the AS, and that Alice's "ID" is what's conveys back to the RS
- fits when paths/uris at the RS are not specific (eg /me/profile vs
/alice/profile)
- gets back into the relationship manager profile, where Alice pushes
RS known sub to the AS which can be returned to the RS through
introspection (or the RPT)
{
"access_token":"sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
"token_type":"Bearer",
"resource_type" : "http://resourcetyperegistry.com/a/resource/type" <-
this is the contract with the client over what the response from the RS
will be
"resource_location" : "http://thisspecificrs.com/path/to/resource"
}
// this is a non-conforming to oauth2 as the access_token isn't a string
{
"access_tokens":[
{bearer access token with resource location}
]
"token_type":"Multi"
}
As client C used by RqP Bob, want to be able to request access to a set of
Alice's resources directly from Alice's AS on Bob's behalf without
knowledge of their location, because I(client) don't have to retrieve the
locations first.
- the client doesn't have to collect a resource location from Bob before
starting the flow, can have a direct relationship with the AS
—
From:
https://groups.google.com/g/kantara-initiative-uma-wg/c/f0g98sr22Rw/m/M5jK9…
As a RO, I want to manage my resources independently of each individual RS
(UMA core prop)
- Alice has resources at many resource servers
- In an ideal UMA world, Alice is able to choose her authorization
server, and all clients are able to dynamically interact with it. Another
case is that the Authorization Server is run for Alice and registers a
specific set of clients. Therefore, Alice/Bob may need to interact with
multiple authorization servers in order to use the clients they want to.
- could we look at the business persons vs user personas
- eg the RS operators doesn't trust certain
- in the bowtie, the RS has 'no-trust' with the client, however this
means it needs trust in some TTP
- this is still an excellent goal, however it requires the RS to
have direct vetting/relationships with all clients. The RS may have
accumulated the resources during some other business purpose and never
intended to become an Authorization Server also.
- As the custodian, the RS has the most liability in disclosing the
resource
As an AS(RS) operator, I need statically registered clients (clients +
RSs), in order to meet my federation assurance requirements
As an RS operator, I don't want to trust any RO chosen AS, because I need
strong federation assurance (I can't trust a individual person)
As an RS operator, I want to register resources with specific trusted AS,
in order to meet my federation assurance
As an RS operator, I want to delegate RP registration and authorization, as
I never intended to take on this responsibility/cost
federation issuance is short-hand for trust framework,
legal/regulatory/compliance requirements (I can't trust anyone)
These necessarily narrow the ecosystem, UMA+these drafts aim to widens the
ecosystem again and remove the need to 1-1 agreements between all parties.
- AS holds the agreements with the Client and RS, no Client<>RS
agreements is required ('no-trust')
- Where does the RO fit into this agreement system? We want to allow the
RO to experience agency as they participate in this ecosystem
- Can we describe the resulting trust model in GDPR terms.
- How does this fit the ANCR receipt, consent token/grant type seems
forced?
- Is a consent receipt from the client a required claims for
presentation?
- The client is the one that Alice's information is disclosed to,
seems like it(the client) needs to be the one providing Alice a
receipt of
this (with the contact information etc)
Alec will attempt to organize these use cases into a document for
solicitation. We need to get less technical and more business/legal
feedback on these goals
As an AS, I want to decouple the consent management UX from the
authorization services,
- less required, but motivates the relationship manager client
As a RO, I need a personally controlled user-agent (UMA Wallet) to manage
my key material, in order to maintain personal-agency in ecosystems
As a RO, I want to authorize a "UMA Wallet" to manage RS resources, so that
I have a single view into my available RS's and Resources
As a RS, I need Alice to authenticate in order to determine which resources
she can manage, in order to ensure appropriate management access
As a RS, I need Alice to establish credentials (pub key), so that I can
trust externally asserted policy was issued with Alice
AS a RS, I need to trust delegations signed by Alice's key, so that Alice
can allow Bob (other keys...) or <<claims gathering condition>> to access
her resources
As a RS, I may delegate resource management user experience, so that I can
focus of my core service to the RO
As an RS, I need to know which AS(s) Alice wants to use, in order to
delegate access control (uma core)
As an AS, I want to delegate RqP identification to a UMA Wallet, so that
- a RqP can choose their private key and consent management provider
- I can avoid directly holding or seeing a users personal details
New term "*BOLTS*"
- Business
- operational
- legal
- technical
- social
UMA Interop Testing
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. Eve
2. Steve
3. Alec
Non-voting participants:
1. Nancy
2. Tim
Regrets:
1. Domenico
From: Andrew Hughes <andrewhughes3000(a)gmail.com>
Date: Mon, Jun 14, 2021 at 11:37 AM
Subject: [KI-LC] Wednesday June 16 2021 - FIRE WG presenting
To: Kantara Leadership Council <lc(a)kantarainitiative.org>
Hi everyone - this month, Jim Kragh and Tom Jones of the FIRE WG will be
talking about recent work on the Trust Registry and how this work is being
introduced to various organizations.
Please forward this note to your WG/DG - The call is open to all.
The call is 9am Pacific / noon Eastern on Wednesday June 16 2021.
We use the first 30 minutes for invited presentations and follow with a 60
minute LC business call.
Call details:
*Leadership Council *
https://global.gotomeeting.com/join/112012805
<https://www.google.com/url?q=https://global.gotomeeting.com/join/112012805&…>
You can also dial in using your phone.
United States: +1 (646) 749-3129
Access Code: 112-012-805
*Andrew Hughes *CISM CISSP
*In Turn Information Management Consulting*
m +1 250.888.9474
5043 Del Monte Ave., Victoria, BC V8Y 1W9
AndrewHughes3000(a)gmail.com
*https://www.linkedin.com/in/andrew-hughes-682058a
<https://www.linkedin.com/in/andrew-hughes-682058a>*
*Digital Identity | International Standards | Information Security *
_______________________________________________
LC mailing list
LC(a)kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/lc
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10
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>
, UMA telecon 2021-05-06
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-06>
, UMA telecon 2021-05-13
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-13>
, UMA telecon 2021-05-20
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-20>
, UMA telecon 2021-05-27
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-27>
, UMA telecon 2021-06-03
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-03>
Eve moves to approve. Steve seconds. Motion Passes!
Charter Refresh (vote)
Please review the Draft Charter 2021
<https://kantarainitiative.org/confluence/display/uma/Draft+Charter+2021>,
changes have been highlighted in red.
Steve moves to approve the Draft Charter 2021 document as the new group
Charter. Thomas seconds. Motion Passes!
(Alec will update the draft and inform the leader council after the call)
Group Leadership (review nominations, vote)
Eve moves to nominate Alec for Chair
Alec moves to nominate Steve for Vice-Chair
Hearing no objection. Passes by Acclamation!
The group would like to thank Eve for her unwavering support of the group
and role as Chair over these many years!
Identiverse Coming-up Soon
Will any one be there "in-person"?
Steve will there if anyone would like to join him
There will be a few virtual attendees
Colin in moderating a mDL panel, and participated in a CAIRN Alliance
panel. Kantara will have a general presentation available. Sal has a
pre-recorded session on facial recognition.
Relationship Manager - draft with credentials
# UMA Resource Server Management
This document extends [UMA Fedz] in order to specify the interface provided
by the RS to the RO for resource management. This is achieved by
introducing a Resource Management API which is used by a Resource Manager
Client to view available resources and direct the AS to use for protection.
** This API could also allows the RO to
- view access history
- set direct policy (ie Adrian clause)
- establish credentials required in AS, (smarthealth.card)
Reqs:
- The RO must authenticate to the RS, in order to authorize access to this
API
- (this capability of the RS is implied by UMA)
- The RO can see a list of resources available at this RS (either protected or
not)
- The RO can modify the protection of resources (ie which AS to protect)
- The RO can see AS's available for protection
- can the RO direct the RS to get a PAT from a new AS? This is tricky
depending on how PAT's are issued (ie may require end-user redirection)
Possible API Names:
- resource management
- resource declaration
- available resources
- resource access management (RAM)
This document introduces the following new concepts:
- Resource Management API The API presented by the RS to the Resource
Manager. This API is OAuth protected
- Resource Management Token (RMT) (what scope should this Access Token
capture?) "uma_management"
- Resource Owner credentials The credentials registered by the resource
owner within the resource server
- Resource Owner Token (or Policies "the VC/VP") A token signed using
the resource owner credentials. Allows the resource server to independently
verify the the resource owner's intention
- Policy Management API The API presented by the AS to the Resource
Manager. This API is OAuth protected
- Policy Management Token (PMT) (what scope should this Access Token
capture?) "uma_policy"
- would also be great if during UMA Grant, the AS could send the RqP to
their Relationship Manager in order for new policy to be created 'just in
time' (ciba-ish...)
- this has been the 'cascading AS' discussion is past. RM provides a
OIDC interface to facilitate the redirect (could be SIOP now?)
### 1.3 HTTP Usage, API Security, and Identity Context
- add link between RM API and RM Token
informative
The use of the `uma_management` scope when requesting a RMT may indicate to
the RS's authorization server that establishment of one or more PATs with
an available UMA AS is 'useful'
#### The `Resource Management API` allows the Resource Owner to:
- View the available resources hosted at this RS, and their current
protection
- Register a Resource Owner Credential
- (eg dyn client registration, posting a DID)
- (for discussion) have verifiable credentials issued by the RS to the RO
- not strictly necessary since the ROT can be created by the resource
owner
- This is a good outcome, since the burden on the RP is moved to the
RO. The RO can present/delegate these VC's further
- Should this draft specify the framework or the specific tech (oauth
client vs w3c) and further profiling of the technical (similar to the uma
grant claims types)
- ~View the UMA Authorization Servers available to be used to protect~
- ~Manage the UMA protection of available resources~
Starting Conditions RMA:
- The RS hosts resources for the RO
- The RS supports resource protection from an UMA AS
- The RS has a UMA PAT at one or more UMA ASs
- **for discussion**A RS that support this profile does not need
resource owner specific PATs. If the ROT is embedded in the RPT, no PAT or
introspection is even required. One RS level PAT to allow introspection,
and opaque RPTs to be issued
- are situations where the RS doens't even know/trust the AS too far?
No?
- the RS implicitly trusts the AS since it includes the authority of
the RO, outcome is RO can use any ASs, moves challenges for having an AS
per RO
Step 0
The Resource Manager obtains an OAuth Access Token valid for use at the
Resource API. The Access Token must allow the RS to determine the RO's
resources.
- is there a purpose for NOT the RO to use this interface? Is this
'delegation' too early in
- *trying to stay away from defining the identity system.
- not necessary to identify the person, instead the RS needs to know the
rights over the resources
Step 1 (Get Info)
The RM obtains a list of available resources
Step 2 (Manage Credential)
The RM registers credentials with the RO
- Viewing and modifying registered credentials
- Registering a new credential
Step 3 (Optional?)
The RM requests resources to be issued as Verifiable Credentials against
one of the registered resource owner credentials
- this would use something akin to https://
mattrglobal.github.io/oidc-client-bound-assertions-spec/
RM->RS: POST /give-me-a-crednetial-for { my_credential(step2), the
resource(step1) } -> issued VC
Ending Conditions RMA:
- The RM has a list of available resources for the RO at this RS
- maybe, the RM has w3c VC's representing the resources
- The RS has attached the ROC(s) to the user account (public part / shared
secret )
- The RM has the RO credentials (private part / shared secret )
#### The `Policy Management API ` allows the Resource Owner(or resource
rights administrator??) to:
- (is this the general resource rights administrator?) doens't need to be
the same as the RO if there has been some RO->RRA delegation in the
background
- view existing policies for them
- create new policies for resources (registered or not?)
Starting Conditions PMA:
- the RMA start and end conditions
- The AS supports the policy management for the
Step 0
The Resource Manager obtains an OAuth Access Token valid for use at the
Policy API. The Access Token must allow the AS to determine the
User(RO/RqP)'s policy.
Step 1 (Get Info)
The RM obtains a list of their existing policies and the AS supported
policy claims
Step 2 (Create Policy)
The RM uses a ROC + resource description + support policy to create the
resource owner token. The ROT is registered at the AS
####
## The Resource Owner Token ( Verifiable Credential or Presentation )
resource owner credential has two part: a identifier and the actual
credential (oauth client id and oauth client secret) (did + private key)
```
ROT = a JWT signed by the ROC {
id: rm create policy id?
resource_owner_id : identifier portion of the ROC
resources: [
resource_server:
resource_id: (similar to how the path identifies the RO to the RS)
resource_location: ??
allowed_scope: [ out of the available scopes ]
]
allowed_rqp: client_id, other claims { email: bob(a)email.com }
}
```
## Available Resources Endpoint (RS)
The API available at the available resources endpoint enables the resource
manager to have knowledge of the resources hosted by the resource server for
the resource owner.
\_rs_id is a resource server defined identifier for a resource.
Before a resource is registered at an AS, there is no handle/reference
available (unless the RS provides one)
GET /my-resources/
```
[
{
"_resource_id" "ABC",
"resource_scopes":[
"view",
"http://photoz.example.com/dev/scopes/print"
],
"description":"Collection of digital photographs",
"icon_uri":"http://www.example.com/icons/flower.png",
"name":"Photo Album",
"type":"http://www.example.com/rsrcs/photoalbum",
// uri/location of the resource?
},
]
```
Protected Resources
```
[
{
"_resource_id" "ABC",
"authorization_sever_resource_id" : "_as_id"
"authorization_server" : "as_identifier",
"registered_scopes" : [ "view" ]
},
{
"_resource_id" "ABC",
"authorization_sever_resource_id" : "_as_id_2"
"authorization_server" : "as_identifier_2",
"registered_scopes" : [ "view", "
http://photoz.example.com/dev/scopes/print" ]
}
]
```
In dashboard world, rs_id = PeI (pension identifier)
- to confirm, is the PeI the same as the as_id? ie is it created by the RS
or the AS
RS_1 holds pension A with identifier a
RS_1 registers pension A
single person, single resource, single rs: can have multiple resource
registration, eg with different scopes
Resource = Patient
Registered Resource 1: Just the Patient Object
Registered Resource 2: The Patient + Sub Objects
### Available Resource Description
A registered resource is a JSON document that extends the resource
description from [UMA Fedz 3.1 Resource Description](1) with the following
parameters:
authorization_server OPTIONAL A string identifying the authorization server
that protects this resource
** could also be the AS policy uri from resource registration?
(1 https://
docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html#re…
)
#### List Available Resource Descriptions
#### Update Available Resources Description
## Resource Owner Credentials Endpoint (RS)
This API available at the Resource Owner Credentials Endpoint enables the
resource manager to view and manage credentials registered for the resource
owner.
GET /my-credentials
```
[
{
_id: cred_id,
cred_type: did | client
cred_value: {
<a did >
...or
<oauth_client metadata>
}
}
]
```
## Resource Owner Policy Endpoint
This API available at the Resource Owner Policy Endpoint enables the
resource manager to view and manager policy registered for the authorized
user
## [UMA Fedz] 5. Token Introspection Endpoint
- needs modification to include the ROT, either to replace a permission, or
an an 'authority' within a specific permission (to be bw compatible)
```
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
...
{
"active":true,
"exp":1256953732,
"iat":1256912345,
"permissions":[
{
"resource_id":"112210f47de98100",
"resource_scopes":[
"view",
"http://photoz.example.com/dev/actions/print"
],
"exp":1256953732,
"authority": ROT.JWT.VALUE
}
]
}
```
## [UMA Grant] 3.3.4 Authorization Assessment and Results Determination
- describe set math changes
- ANCR receipt could be used on first contact with the AS (from the RM).
Establishes the initial terms of this relationship and the delegation of
authority
- (Anchor Notice & Consent Receipt is a extension of the Consent
Receipt (CR 1.2.1), including how it fits into protocol flows)
Next steps:
- defines the change to the AS authorization assessment
- AS → RM. "i don't have a policy right now, maybe you RqP can create
one that fulfills this clients request"
- into ideas of a RO/RqP relationship manager (aka Wallet)
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. Eve
2. Michael
3. Alec
4. Domenico
5. Thomas
6. Steve
7. Sal
Non-voting participants:
1. Scott
2. Colin
