Hi Adrian, I think the pairwise pseudonymous part of this use case falls into the category (like several of the others) of "this is something UMA can generally cover now, and we want to be sure XYZ can also cover it in the future". In fact, as far as I can tell, the pseudonymous nature of all the identities/identifiers (RO-at-AS, RO-at-RS, and RqP-at-Client) holds whether you're using DIDs or not.

In the business-legal framework call series, we recently created a picture to illustrate at least part of the "Alice" side of this; see slide 5 here. (Any WG participant who doesn't yet have access to the deck, just request it.)

As for the token-as-capability that can itself be delegated to and reused by a different entity: we use OAuth access tokens (although a bit customized). They're not designed to be passed along and used by someone/something else. So you may want to write up that part separately.

Eve Maler
Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl



On Thu, Sep 19, 2019 at 8:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
I'm sorry that I missed this call but I'm not sure I would have been able to follow the jargon anyway.

My principal use-case is:
(i) to have a W3C standard DID, possibly a pairwise-pseudonymous DID for each RS, point to Alice's AS at resource registration time. Then later,
(ii) when Bob shows up to the RS with his client, I would assume that Alice's AS or some delegate of Alice's AS, has given the RS a token that represents a capability (that Bob can delegate further) rather than an identity.

That implies that any claims conversation prior to (ii) between Alice's AS and Bob, Bob's DID, or Bob's client has not much to do with the RS.

If Alice's claims gathering relationship with Bob is also assumed to be pairwise-pseudonymous between them, how does Bob's client refer to Alice when it approaches the RS with some kind of capability?

Adrian

On Thu, Sep 19, 2019 at 11:40 AM Eve Maler <eve@xmlgrrl.com> wrote:

Minutes

Roll call

Quorum was reached.

Approve minutes

MOTION: Approved.

XYZ use cases

UMA-related use cases collected last time:

  • AI: Eve: Alice-to-Alice sharing (RO-to-self)
    • In Justin's description of the "multiple parties" use case (which is generally the "UMA use case"), he says "UMA extends this to allowing the Requesting Party to be the one using the client, but it generally doesn’t collapse cleanly into the cases where the RO is the party using the client since the claims gathering endpoint and the authorization endpoint aren’t quite the same in concept."
    • However, this doesn't seem right. What should happen is that RqP (that we happen to know, if we are outside the system, observing, that the policy happens to match Alice-again, is the RO) should be taken not to the authorization endpoint but to the claims interaction endpoint. We confirmed that Gluu's implementation, e.g., does it this way. If there is no policy whatsoever in place, then Alice-the-RqP's client might get, say, request_denied and Alice-the-RO might be given the opportunity to create a policy for the first time that happens to match herself.
    • AI: Eve: Reach out to Justin to discuss this use case.
  • AI: Eve: Proactive Alice-to-org sharing (RO-to-client developer, so to speak)
  • AI: Peter: Bob is assured to a certain level that Alice is who she says she is (strong Alice-to-AS binding or "CIBA-like")
  • Transactional and long-term management of sharing of preferences with service providers

Eve had some one-on-one discussion with Justin about the intended design center of XYZ, transactions, and guessing what might be the impact on client ecosystems (e.g. reducing friction or adding friction). The big security impact is intended to be narrowing the scope and moving from bearer to sender-constrained tokens, and doing it in a simpler and consolidated way, hopefully easier for everyone, including clients. As we push the boundaries of what OAuth was intended to do, it makes sense to refactor. The rise of the Janrains and Gigyas back in the day was a response to OAuth complexity. Anything that sits in the middle that says "redirect to us" – a central session management service – is even simpler.

What makes it complicated is making the client smart enough to know what profile to enact. Each profile (e.g., FAPI) has different security characteristics. A key part of the complexity is the number of specs and resulting amount of knowledge you need. This sounds a bit like the Active Directory PAC (privileged attribute certificates) structure history. Do we need one gigantic token that covers all the complexity as the solution? The way to punch out of this paper bag is to get really familiar with all the use cases and truly get experience with the solutions.

  • Semantics for transactional-level permissions (scope and/or resource)
    • This one looks covered by Justin's writeup.
  • AI: Cigdem: Disconnected RS when a "handle" for the RS can't be gotten right away
    • XYZ has a strawman for C-to-RS
    • ACE has a disconnected RS flow and doesn't use a permission ticket – the ACE model also has a "client AS" where the client itself might be offline
    • Liberty had a model where an offline IdP could give the client a delegatable token that would allow the client (using the PAOS profile – reverse SOAP...) to mint tokens in a disconnected manner – Thomas notes that these would be considered forwardable/proxyable tickets

ACE for a time had a use case for an RS could be a proxy that could help reach an AS for a client if either the RS or client had difficulties getting online, but Hannes did a security analysis that seemed to cross that option off the list. Our model would seem to make this highly unlikely to be practical if the AS and RS were loosely coupled. If you have an entirely sender-constrained-token model such that the RS is just an SSL tunnel between the client and AS, only then would it be safe for the RS to proxy token issuance messages. But it seems the paper concludes this is just unwise at all.

The last set of use cases to be documented aren't UMA conundrums at all but simply use cases UMA actually solves over and above OAuth today:

  • AI: Eve: Existing UMA use cases that are described in our Grant and FedAuthz spec introductions

Next time, let's review people's use case write-ups, including Justin's existing ones.

Nominations for chair and vice-chair

Let's take up the actual ballot next week.

Thursday meeting series

Thoughts on making this a biweekly series in Q4? Some sentiment "for". Let's decide next week.

Attendees

As of 16 Jul 2019, quorum is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem)

  1. Domenico
  2. Peter
  3. Maciej
  4. Eve
  5. Cigdem

Non-voting participants:

  • George
  • Vlad
  • Thomas
  • Colin

Regrets:

  • Andi
  • Mike

Eve Maler
Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma


--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma