https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16
MinutesRoll call
Quorum was NOT reached.
Approve minutes
- Approve minutes of UMA telecon 2021-09-09
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-09>
Deferred
Correlated Authorization
https://github.com/uma-email/poc
Today in UMA can push the token, addition is binding the ticket to the
pushed token
There's nothing bad about this claim token profile, not sure what the
specific use-case or outcome it tries to create
What is the motivation for needing the correlation? Is there a specific
outcome the correlation creates over 'ticket challenge-less' claims pushing?
- not allowing RpQ token reuse. Is this beneficial? is it tied to the
first use of that token and require re-issuance if the AS needs_info
- non-interactive RqP id assertion
OAuth vs UMA content
Since this a common information request, could we create some good standard
content/position?
EIC Points:
OAuth
- Tokens issued to a Resource Owner at a Client
- Communication between Resource Server and Authorization Server is out
of scope
- this necessarily 'narrows' the ecosystem, since the RS and AS need
to agree ahead of time on authorization details
- usually RS/AS are in the same domain (eg TLD)* Is this something
that OAuth says or is it what people naturally implement?*
There are OAuth extensions that drive to UMA-like outcomes, such as Token
Exchange <https://www.rfc-editor.org/rfc/rfc8693.html> which allows a
Client to get a token representing another party. Or GNAP which takes a
bunch of UMA + OAuth features and derives a new authorization protocol.
Typically considered as 1 RS and 1 AS, with many RPs/clients
UMA
- Tokens issued to a Requesting Party at a Client
- Defines API between RS and AS for: resource registration, permission
ticket creation and introspection
- There can be "many of everything" not just Clients ← this is a "hard"
concept for people to grasp at times
People ofter struggle with the 'nicknamed tokens', understanding they are
access token which specific scopes/purposes. PCT has often been a hard one
to understand, not widely implemented today because of this?
UMA Outcomes:
- RO to RqP delegation,
- decouple consent(policy settings, consent as pre-condition for any
tokens/grants) from transaction(token issuance), can happen ahead of time
or just in time
- AS Discovery and RO selected AS,
- Request and grant for specific fine-grained resources, doesn't look at
an entire RS as the resource but allows arbitrarily small resource
registration
UMA is very flexible and comprehensive, which creates it's own set of
interoperability challenges. Requires interop/ecosystem profiles which
immediately undercut the UMA goal of wide-ecosystem.
- Even client registration at the AS is challenging. UMA implies that
it's dynamic since 'any client can be used', however this isn't in wide
practice today (most clients today are pre-registered)
- culmination of different barriers (technical, common practice,
understanding) that make UMA difficult to use in practice
Trust Registry helps with decentralization and creating a more informed AS.
More granularity around the purpose, state for authorization and checking
for changes (new role for PCT?) Captures, AS endpoint, purpose, scope of
permissions. There will be many of them, ideally not too many for each RS.
How do they interact? Regional/local collaboration, and then combining
regional networks with congruent code of practices to create a wider
ecosystem.
Topic for future weeks: outcome of user stories discussion, PDP
architecture includes the concept, TOIP/SSI are starting to define this
ecosystem function
Topic for future weeks: ANCR records update, Privacy as Expected.
AOB
https://www.ontario.ca/page/consultation-policy-framework-ontarios-digital-…
Feel
free to submit comments to Ontario about the DI strategy
Alec will be away next week
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. Sal
Non-voting participants:
1. Zhen
2. Ian
Regrets:
1. Eve
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16>
Hi all,
I have been thinking for a long time how to convey information about the
user from an identity provider to an authorization server, especially
across security domain boundaries. This is difficult to implement because
OAuth2, OIDC and UMA are single-authority protocols. That's why I tried to
extend the UMA protocol to a dual-authority protocol. Please find a short
draft proposal here: https://github.com/uma-email/poc
I would be very interested to know if this is the right way to do it and
what you think about this idea.
Disclaimer: Although I present the idea of the correlated authorization as
a new protocol, if adopted and refined by the working group, it could be
referred to as the UMA wide ecosystem.
Regards
-Igor
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-26
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>
, UMA telecon 2021-08-19
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-19>
Deferred
Minimal Interop Profile
Let's get to some test cases/requirements?
PAT is fairly impl specific, could be given to the Mock RS test suite
- auth code flow
- can become first point of non-interop
Goal: make sure that AS's are interoperable , eg one AS can be 'swappable'
with other ASs. Understanding of 'extras'/vendor specific values that
degrade that interop. As an RS the more ASs I can support define the 'wide'
ecosystem I can support
Scope of test
- 1 AS under test
- 1 Mock RS test suite
- 2+ ROs
- clear success cases (including error conditions)
- response testing for unexpected values returned → WARN
- Minimum Viable ONLY
Input to Mock RS Test Suites
- name of 'rreguri' endpoint at the AS
- multiple PATs to represent the RO context
- at least 2
- value for _id, ie what key will the AS return
- resource descriptions keys supports
- Only required content is resource_scopes
- Optional to push other keys (type, desc, name, icon_uri)
- create support for user_access_policy_uri
- use of introspection
- optional support for exp, iat, nbf (maybe too much since this is
OAuth introspection scope)
1. resource registration
1. Error cases
1. PAT less requests
2. get/put/delete, requests without known id
3. leaking between PATs
2. Create resource description: POST rreguri/
- should always work, returns new id
- performs 5+ times for each PAT
3. Read resource description: GET rreguri/_id
1. ready all created
2. should always work for returned ids
4. Update resource description: PUT rreguri/_id
- should always work, return same id
5. Delete resource description: DELETE rreguri/_id
1. should always work
2. removed from list after deleted
3. future: effect on RPTs/tickets
6. List resource descriptions: GET rreguri/
1. only returns created resources for this PAT
2. likely interjected between other cases, ensure state is
reported accurately
2. permission ticket creation
1. all scopes for single resource
2. multiple resources, all scopes
3. single resource, subset of scopes
4. multiple resource, subset of scopes
5. error cases
1. wrong resource for PAT
2. wrong scopes for resource id
6. future,
1. AS overriding resource/scope sets
3. introspection (optional)
1. keep in mind, introspection is an OAuth defined item, want to
limit to UMA defined functionality to remain minimal viable
2. RPT issued with all resources from permission ticket
3. RPT used with correct PAT
4. active:true, must have the 'permissions' array
5. how to test active:false response?
1. would require manual intervention at the AS?
6. error cases
1. wrong PAT for RPT
7. (future) AS imposed changes based on policy
The test suite could be 'random' ie for scope generation?
Real application, UMA protect userinfo (OIDC scopes)
Relationship Manager - user stories / *Discovery*
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
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…
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. Alec
3. Steve
Non-voting participants:
1. Scott
2. Anik
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
