UMA and Claims
Tuesday – Session 4 - C
Convener: Tom Holodnik
Notes-taker(s): Eve Maler, Tom Holodnik
A. Tags for the session - technology discussed/ideas considered:
B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Notes from Eve Maler:
See Tom's slides: http://kantarainitiative.org/confluence/download/attachments/37751312/UMA+Claims+-+IIWX.pdf
UMA has two really great ideas in it: dynamicism and claims. Dynamicism is by its nature inclusive, and claims are by their nature exclusive.
Claims are going to have to support both self-asserted data and third-party-asserted data. And there are even ways of authenticating a "walk-up" requesting party that are so lightweight that they feel like self-asserted data. E.g., if in the process of engaging with a future requesting party in person (your dentist) you give them a tear-off paper with a unique temporary password that they need to present when seeking calendar access, you've authenticated them pretty strongly and only need to correlate "the same party" in future.
If you want to share dental records on a more formally authenticated basis, other things might have to happen.
UMA needs to have a unified way of "being" a requester endpoint, even if it has different flows for how they are interacted with. We think we have that now.
Should a specific person at a company be given access to Alice's stuff, or should a role at the company (or just generically "the company") be given access? The former is brittle.
What if you want to grant any plumber who has a good certification rating access to my plumbing service record? There will be company and certifier assertions involved.
Claim format definitions clearly need to have a generic/horizontal core set, and likely we would need domain-specific plugins for specialized policies and claims.
+++++++ Notes from Tom Holodnik:
Summary: So far, only simple forms of UMA claims are currently defined. Under our current understanding, we can either have support for broad dynamically configured access management circles of trust with relatively low requirements for trust, or we can have strong assurances of identity and legal certainty but with rigidly defined circles of trust (e.g., JSONifying SAML). That is, we can either have broad and shallow circles of trust, or narrow and deep, but nothing in between.
Currently defined claims models are defined here: http://kantarainitiative.org/confluence/display/uma/Claims+2.0 and here: http://kantarainitiative.org/confluence/display/uma/Simple+Access+Authorization+Claims
The kinds of claims we support now are self-asserted claims such as "Are you older than 18?" and "Will you comply to these licensing terms?" Any claims that demand that someone assert an identity with any level of assurance are yet to be defined.
We got bogged down in a conversation about ontologies and grammar for claims. In the writers opinion, this missed the point of the session- this was to understand the goals for claims and less about how claims are expressed.
Regardless of the way it's expressed, it needs to be decided whether we're simply translating SAML assertions into JSON within a closed Circle of Trust, or whether we're attempting to build an internet-scale system for provisioning and processing claims of identity and other attributes.
That said, the user who establishes a relationship with an UMA Access Manager shouldn't have the expectation that the AM will serve as a directory of service providers. The idea is that the AM has only enough infrastructure to support validating claims- it doesn't promote only those requesters that it has a relationship with. An UMA AM is not a VRM.
