https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-09-03
MinutesRoll call
Quorum was not reached.
Approve minutes
- Approve minutes of UMA telecon 2020-07-09
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09>
, 2020-07-16
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16>
, 2020-07-23,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23>
2020-07-30,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-30>
2020-08-06,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-06>
2020-08-13,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-13>
2020-08-20,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-20>
2020-08-27
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-27>
Deferred.
PKCE status
Alec edited the UIG with the new text. People can take a look and see what
they think.
Relationship Manager profile
See the policy manager API in this email thread
<https://groups.google.com/g/kantara-initiative-uma-wg/c/1BcBSR_FnJA>. Also
see Policy Manager Extension #363
<https://github.com/KantaraInitiative/wg-uma/pull/363>. Eve proposed a list
of things to discuss and Adrian added one more thing:
- One API (AS only) or two (also RS)?
- (Each) API protection model?
- Topological and trust assumptions or lack thereof? What can be
co-located? How many of each thing can there be?
- Any rules needed for policy (“policy condition”) priority between RM and
AS (the “cascading” scenario)
- A clean way to model or illustrate the scenario when the RS is hosting
claims (the “turtles” scenario)
- Customer requests for functionality that Eve discussed last time – this
was the discussion of consent management servers (CMS's)
Would these (putative) CMS's have "read/write" APIs that allow resource
owners to "put policies into" any of the servers? (What Adrian has been
thinking of as bidirectional APIs.) Nancy notes that think hasn't been
discussed in quite some time and these don't exist yet. A privacy concern
is that a user (RO) who has a policy that touches on, say, HIV information
would be potentially revealing to a server that they have HIV. Adrian
agrees that policies are personal information – "they need to be protected
as if they were private keys". Organizational policies of the enterprise,
which could include authorization policies and other operational policies –
should be safe. The RS gets to publish openly any "XACML fragments" (bits
of policy, doesn't have to be XACML) that represent its own policies. The
AS gets to pick up these fragments and combine them with whatever policies
the RO chooses to add. (If XACML is actually used, then this usage pattern
exemplifies a way that it was meant to be used – combinatorially, with
priority able to be established.)
"Consent work" would need to be done to figure out the downstream privacy
implications of combining these policies. Where would this work take place?
HEART? Here? Somewhere in the SSI community? Eve has been wondering how bad
the situation is wrt policies as PI: doesn't any one AS have to know some
policies (if not "all the policies of an RO") in order to function, and so
doesn't some PI have to pass to a server that may possibly at best be a
limited fiduciary?
The requirement Alec was trying to meet was for the AS – through the
relationship with the RM (or PM or whatever we end up calling it) – to not
see PHI (PI) such as an email or birthdate of the RO's. The "Nancy paradox"
is that policies are also PI. The policy manager gives the opportunity to
generate random UUID's and tie those to the relevant policies that the AS
needs in order to grant access, issue tokens, etc.
This was also the motivation for the resource definitions work. If a RO
uses a service/app (client) for the first time and doesn't trust it (fully)
yet, they can nonetheless see the scopes and resources they're about to
grant access to by virtue of the client becoming "operational enough"
through meeting the requirements for the patterns it was registered for.
Andi asks: How much of this needs to be made interoperable in a spec, and
how much of this is implementation choice? Alec brought up the pseudonymous
stuff because that's what they implemented. We totally want to understand
if there are multiple applications of the base technology. For example,
Domenico's work illustrating a "widget" for a policy manager way back when
(see slides 10 and 15 here
<https://www.slideshare.net/domcat/uma-trusted-claims>) was one such
application. Slide 15 in particular shows how Alice is protecting her photo
with UMA. Bob is presenting claims in order to get access to it. What if
those claims are UMA-protected? Can we call that a "trusted claims"
scenario? (Eve was calling that the "turtle" scenario for "turtles all the
way down" but that didn't gain favor.) This scenario doesn't depend on
using policy managers but could use it.
What scenarios do we actually have here? What does "cascading" mean? Eve
thought it was combining policies from multiple sources so that an AS can
function when it needs to. There is only one final AS that operates to
grant access and issue access tokens, even if there are multiple AS's (as
in the Pauldron/VA type of scenario).
Adrian has testified that something like HEART's "btg" ("break the glass")
scope implementation scenario should be an instance of the *RS* (not the
AS) needing to being able to observe a jurisdictional or regulatory policy,
and so it needs to use the "Adrian clause".
If we are able to nail down these concepts and terms, do we require an
interoperable policy language to make any of them work, or not?
Attendees
As of September 3, 2020 (pre-meeting), quorum is 5 of 9. (Michael,
Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve)
1. Michael
2. Domenico
3. Andi
4. Eve
Non-voting participants:
- Alec
- Patrick
- Scott
- Adrian
- Nancy
- Tim
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
We continue the relationship manager work. Some things I think we need to figure out (ideally from proposals or lists of options):
- One API (AS only) or two (also RS)?
- (Each) API protection model?
- Topological and trust assumptions or lack thereof? What can be co-located? How many of each thing can there be?
- Any rules needed for policy (“policy condition”) priority between RM and AS (the “cascading” scenario)
- A clean way to model or illustrate the scenario when the RS is hosting claims (the “turtles” scenario)
What else?
Eve Maler (sent from my iPad) | cell +1 425 345 6756
Hi,
To our discussions, I’ve started to break out just the RO policy manager component of the original wallet spec
Best,
- Alec
Alec Laws
647 822 1529
alec(a)identos.ca
—
## 1. Introduction
This document extends [UMA Fedz] in order to specify the interface provided by the AS to the RO for policy management. This is achieved by introducing a Policy Management API specification and client type which represents the RO: the UMA Policy Manager.
This new client type is authorized to use the policy API after being authorized by the RO as the AS. THis is the same mechanism used by an RS to put resources under protection, the RS is issued a PAT by the AS.
This new client provides a few key benefits to an UMA ecosystems
- The AS may delegate policy management user expereince and advicce to another party
- The RO is able to choose this client, where they may not be able to choose an AS or RS. The RO receives a consistent policy management interface
- The RO may manage resources at many AS's to have a complete view of their resources and policy
For example, there are two UMA AS's, one being operated by the Alice's local health authority and one operated by Alice's personal Bank. Alice's resource servers are only able to accept authorization decisions from those RS, effectively Alice must use those RSs to protect her resources. When those AS's support this profile, they give back some agency to Alice in how she manages her resources and policy, and reduce their own need to provide this UX (maybe each AS provides on UMA Policy Manager by defaults, but also accept third party policy management services). Alice may then manage policy across all of her RS's and AS's from a single control panel.
### 1.1 Notational Conventions
### 1.2 Abstract Flow
```
+------------------+
| resource |
| owner |
+------------------+
|
|
v
+------------------+
| Policy |
| Manager |
+------+-----------+
|
|
manage (a PAT type authz?)
|
|
v
+-----------+
| policy |
| API |
+-----------+
+---------------+--+
| |
| authorization |
| server |
| |
+------------------+
```
This specification uses all of the terms and concepts in [UMAGrant] and [UMA Fedz]. This figure introduces the following new concepts:
- UMA Policy Manager
- Policy API The API presented by the AS to the Policy Manager. This API is OAuth protected
### 1.3 HTTP Usage, API Security, and Identity Context
## 2 Authorization Server Metadata
TBD
## 3 Policy API
note: this API is very similar to the permission endpoint, expect the payload includes an RS sub, additional policy condition, and is signed by a RO-RS credential
The API available at the policy_endpoint enables the policy manager the modify policy over the RO's protected resources. These policies define the claims gathering requirements for an RqP to gain access to the resource, and should also indicate the intended purpose/use for resource access. Management of the policy beings on successful creation and ends on successful revocation.
The relationship manager uses a RESTful API at the authorization server's policy endpoint to create, read, update, and delete policy descriptions, along with retrieving lists of such descriptions.
note: I think it's also useful to allow the RO to read a list of registered resources, I don't think would live under the policy_endpoint, it's essentially like the GET API from the resource_registration_endpoint with additional information about the RS?
note: through the ` "user_access_policy_uri":"http://as.example.com/rs/222/resource/KX3A-39WE/policy"` the RS could also let the relationship manager know (though manage API) what path to use at the AS to modify policy for this resource?? This restricts
Figure TDB illustrates the policy API operations, with requests and success responses shown.
```
FIGURE TDB
```
- user authz to use the API, same as RS getting a PAT -> continuity of resources, "account at the AS"
- read rs's
- read registered resources
- organized by RS?
- manage policy
- resource(s) + acceptable claims conditions
### 4.a Policy Description
A policy is a JSON document, that describes the a policy sufficiently for the authorization server to make a decision for a resource request. A policy document MAY be provided as a signed JWT to ensure it's integrity to the RS during enforcement. A policy description has the following parameters
resource_id REQUIRED The resource id registered at the AS that this policy applies to
resource_scopes REQUIRED The approved scopes if the claims requirements are met
claims REQUIRED An array of claims/attributes that must be presented by the RqP in order to access this resource under this policy
optional/extension/discussion:
sub The subject known by the RS for this RO (useful for general resource definitions)
resource_server (again, useful for general resource definitions)
client_id The client application that may be used to access this resource
intent The purpose/intention of resource use the RqP must accept
For example...
```
{
resoruce_id: "KX3A-39WE",
"resource_scopes": [
"read-public",
"post-updates",
],
claims: [
???
]
}
```
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-27
MinutesRoll call
Quorum was reached.
Approve minutes
- Approve minutes of UMA telecon 2020-07-09
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09>
, 2020-07-16
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16>
, 2020-07-23,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23>
2020-07-30,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-30>
2020-08-06,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-06>
2020-08-13,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-13>
2020-08-20
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-20>
Deferred.
Sustainable Self-Sovereign Agents (S3A)
There was a meeting held earlier today – notes and a recording here
<https://docs.google.com/document/d/1kZ7_Skcn4zb3zOfEu7XZDrYAmLR1T_pbBoSk8AE…>.
For more info or to get involved, contact Adrian. UMA is being put in play.
PKCE and UMA wrapup
Any final *quick* comment on this? Alec has suggested some updates to his
latest wording in this email thread
<https://groups.google.com/g/kantara-initiative-uma-wg/c/t72iQgd2qEU>,
though he's not perfectly happy with it. Eve suggests putting it in the UIG
anyway, and drawing people's attention to the (non-normative) wording for
use and comment.
Adrian notes that a UserInfo endpoint, interacted with in a fashion that is
sort of variable in the SSI context (e.g. the first contact could be a QR
code), could be an interactive claims gathering endpoint. We have also in
the past discussed how we need notification functionality, which requires
out-of-band endpoints.
Relationship Manager profile
Alec sent thoughts on the policy manager API in this email thread
<https://groups.google.com/g/kantara-initiative-uma-wg/c/1BcBSR_FnJA>.
Let's see if we can capture a deeper "why"/comparison statement that could
go into the profile. (See the openings of the UMA2 specs for an example.)
Alec's new wording does contain this sort of why/comparison/motivation. In
other words, in the case where the AS is a "multi-user" AS and Alice (the
RO) has no choice about which one it is that she has to use, we want to
make sure to preserve as much of Alice's agency (control) in the situation
as possible. So pushing policy management out of the AS and into a client
app gives Alice this point of control. She wants some freedom to
independently verify who is providing advice about what policies to choose.
We have, in the past, discussed AI engines that implement things like
relationship-based policy. This client could provide such functionality.
The token that protects this policy management interface is different from
the PAT but is similar to it. Let's call it a "PMT" right now, for
argument's sake.
The FPX work that is being dropped here is the policy manager's interaction
with the RS. The previous discussions we were having about "cascading" AS's
had to do with the situation when the server-side (multi-user) AS might
hold some policy and the client-side (Alice-specific) relationship
manager/policy manager might hold some policy too, and then you have to
figure out policy ordering. But Alec has left that out for the sake of
simplicity.
Adrian objects to working on this profile because it optimizes for a
situation where the server-side AS isn't Alice's fiduciary. Alec believes
there is nothing in the profile that precludes the RS from presenting 10
AS's and letting the RO choose. Eve believes that Tim has previously
concluded that any server-side AS that serves multiple users would have a
hard time being anything more than a limited fiduciary (but we have to
check). As well, a key requirement expressed by a number of healthcare
players has been to "federate" policy management across multiple servers,
so this seems to be consistent in a certain sense. Her past discussions
with Nancy revolved around "consent management servers" (CMS's) and she
brainstormed a "consent access token" (CAT?) to protect a "consent API".
Domenico notes that PSD2 has the concept of a collector – an aggregator of
data from multiple bank institutions. This is what this "RO client" (can we
call it that? Thomas suggests it) enables the RO to do with policies,
across any number of AS's, whether the RO chose them or not.
Scott has been context-switching every time he hears "client", thinking it
means our classic "UMA client" that the RqP uses, so we should also qualify
"client" when we mean the one that the RO uses.
Should we go back to the RO-client interfacing with both AS's and RS's?
Let's think about that.
Adrian loves the notion that the market wants some kind of policy
management wallet or agent. [image: (smile)] Is this bidirectional? Is it
a read/write API? He suggests extending the "Adrian clause" to the AS as
well the RS. Let us ponder that.
Eve adds on top: We may want to think about another modular profile that we
should consider drafting, a "prove to Bob that Alice is who she says she
is" profile, now that we'll have an RO-client that incidentally allows for
Alice-authentication. This would help us solve for CIBA-like use cases
(which we've discussed ad nauseam before).
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
MyData is offering the SSI communities a significant platform to promote
our standards and broaden our outreach at and around their annual meeting
in December.
I'm organizing a program proposal on DID and UMA-centered interoperability
and hoping for broad participation. The details, including a novel idea,
are in this document:
https://docs.google.com/document/d/1kZ7_Skcn4zb3zOfEu7XZDrYAmLR1T_pbBoSk8AE…
Please join a program planning Zoom 8/27 10 AM EST.
- Adrian
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-20
MinutesRoll call
Quorum was not reached.
Approve minutes
- Approve minutes of UMA telecon 2020-07-09
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09>
, 2020-07-16
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16>
, 2020-07-23,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23>
2020-07-30,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-30>
2020-08-06,
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-06>
2020-08-13
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-13>
Deferred.
PKCE and UMA; why to identify clients; who has a stake in identifying
clients
Discussion with George: As long as the permission ticket is refreshed on
every claims gathering round (which it is), and only the most recent
permission ticket is accepted in the next round (which it should be), we
should be okay. PKCE is trying to prevent "waking up someone else's app".
Android doesn't have quite the same discipline as Apple around scheme/app
checking. Our analogy is permission ticket .eq. authorization code. If the
code challenge is sent in an ICG flow, does it have to be sent to the token
endpoint? We might need to provide some direction around what to do if the
client generates the new value, or possibly say it shouldn't. Is getting
the same hash multiple times better than multiple hashes in multiple
rounds? Interception of the response would be the problem. We could write a
profile of DPOP. The client could pass in its key, which would get bound to
the permission ticket. That would prevent any intercepted message from an
alternative client from being interpreted as legitimate. We could also be
more prescriptive around DCR. DPOP was meant to help in the situation
around SPAs. For mobile apps, you register it with the AS, and then you can
use whatever POP method you want. OAuth 2.1 helps a bit (as previously
noted) because PKCE is mandated; this brings client identification. DCR
brings a persistent client identification and authentication mechanism.
AI: Alec: Continue to massage the UIG blurb to include these new insights.
In a bring-your-own-device context (which we now frequently see in
healthcare and other sectors), we're finding it important to dynamically
register (identify and subsequently authenticate) UMA client applications
used with those devices. Adrian notes that there is some trouble out there
handling software statements for clients. And he's aware of US law that
says that a client application unrecognized by an AS can't be refused, and
its user, the patient, can only be issued a "black box warning" (there is
no distinction in the law between blocking the client and blocking the
patient). George believes UMA fits in this model quite a bit better than
OAuth because it doesn't require "trust" in the client. Then a process
begins to look at proof around the RqP entity against the policies
protecting the resource.
There is little awareness among people not at this table that RS's are able
to outsource client management to the AS simply because the client can
remain relatively untrusted; as long as the client is simply persistently
identifiable throughout a single run of the protocol (it's "the same dog"
throughout), it shouldn't much matter what it actually is, because claims
would be gathered about the RqP to satisfy policy in granting resource
access. Even though this feature is native to UMA, the resource definition
profile seems to enhance the comfort level of RS's in making the AS a kind
of community trust anchor for clients (not the original purpose of the
profile; it just worked out this way). Could we complete a deeper analysis
of the native feature and then publicize it better?
Leveraging RAR for the client presenting claims could be interesting, and
PAR could be used as a security technique as well.
Adrian mentioned the work of IEEE's "P2933 - Clinical IoT Data and Device
Interoperability with TIPPSS (EMB/Stds Com/Clinical IoT DDI... Home".
George mentioned: "Google's WebID proposal is in the W3C Incubator
Community Group (WICG) and Apple's isLoggedIn() proposal is being discussed
in the W3C Privacy Community Group (WPCG)" If people can get involved in
these communities, that's helpful. Not directly related to UMA, but browser
support for identity stuff is relevant.
Lots of stuff we could profile here, in order to take advantage of new
OAuth-related tools to strengthen UMA's abilities.
Relationship Manager profile
Alec's latest spec text is in this thread
<https://groups.google.com/g/kantara-initiative-uma-wg/c/vcB9S3mksn8>.
Deferred this time.
Attendees
As of July 8, 2020, quorum is 6 of 10. (Michael, Domenico, Peter, Sal,
Gaurav, Thomas, Andi, Maciej, Eve, Mike)
1. Michael
2. Sal
3. Thomas
4. Eve
Non-voting participants:
- George
- Scott
- Adrian
- Anik
- Alec
- Colin
*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter:
@xmlgrrl
