Alice to Bob resource sharing

So I was in UMA call today and that reminded me of this use case.

How does Alice share her protected resources (like medical test result) to Bob?

I may have bloged in the past, but here is another try.

The requirements:

  1.  Alice needs to give permission to Bob to access her resource; 
  2. The resource needs to be able to find out the fact that Alice has given the permission. (policy);
  3. The resource needs to make sure the entity that accessing it is Bob;


  1. Alice and Bob has OpenID Connect Identity provider (OP) of their own; 
  2. The resource has been registered at Alice’s authorization server and the accounts at the resource and the authorization server is linked somehow.;
  3. Alice has to know Bob’s identifier in Alice initiated flow, and Bob has to know Alice’s identifier in Bob initiated flow.

There can be two kind of work flow:

  1. Alice initiated flow (Alice giving the permission to Bob and Bob access the resource); 
  2. Bob initiated flow (Bob requests the claim; Alice approves it; Bob access the resource);

WF1: Alice initiated flow (Alice giving the permission to Bob and Bob access the resource)

This is an Alice initiated flow. In this workflow, it proceeds as follows:

  1. Alice access the endpoint that let her create the policy / authorization (AM in UMA?) for Bob to access her resource;
  2. Alice is redirected to her OP and gets authenticated and bounced back to the AM;
  3. The AM shows Alice the URL that Bob can use to access the resource. (Note: URL may have the policy encoded in it so that the servers can be stateless) In Link-Rel terminology, the type of the resource (e.g., the medical test result) is ‘rel’ and the URL is the ‘link’;
  4. Alice sends the URL somehow to Bob (e.g., email);
  5. Bob access the URL;
  6. Since URL is protected, Bob is bounced to his OP. (Note: At this point, the resource server has to be registered at Bob’s OP as a client.) ;
  7. OP authenticates Bob and bounces him back to the registered redirect URI, say with ‘code’;
  8. The resource accesses the token endpoint of Bob’s OP to get his ID Token;
  9. The resource examines the ID Token and finds out that the person accessing is Bob through the ‘iss’ and  ‘sub’ claim;
  10. The resource returns Alice’s medical test result to Bob’s browser;

The trick here is the ‘link’. The ‘link’ has to contain some state information that can be used to look up the policy that Alice has set. It could either be completely encoded in the URI or the resource server may resolve the policy from the state. Apart from that, there is nothing special. It is just the standard OpenID Connect repeated twice; one each for Alice and Bob. Also, it would be worth noting that to achieve this, Alice somehow has to know Bob’s identifier, such as email so that Bob can prove that he is the legitimate holder of that identifier.

WF2: Bob initiated flow (Bob requests the claim; Alice approves it; Bob access the resource)

This is Bob initiated flow.

  1. Bob does a lookup through Webfinger etc. to find out Alice’s AM endpoint;
  2. Bob requests access to ‘medical test claim’ to Alice’s AM endpoint;
  3. Since Bob is not authenticated, he is redirected to his OP. (He may have to chose one in the Account Chooser etc.) ;
  4. The OP authenticates Bob and get him back to the endpoint with ‘code’;
  5. The AM resolves ‘code’ and gets Bob’s ID Token;
  6. The AM returns the page saying ‘Authorization Pending’ etc. with the link URL that he can use to access the resource once Alice authorizes.
  7. The AM sends the notification to Alice with a link via email, SMS, etc. (SPAM is a problem here.) ;
  8. Alice gets the notification and clicks on the link (AM).
  9. The link (AM) bounces Alice back to her OP to get her authenticated after which she returns with a ‘code’;
  10. The AM resolves ‘code’ to get ID Token and finds out that it is Alice;
  11. The AM shows the authorization consent page to Alice;
  12. Once Alice agrees, notification is sent to Bob.
  13. The rest is the same as the WF1: Step 5 and after.


4 Replies to “Alice to Bob resource sharing”

  1. Hi Nat,

    I believe both WF1 and WF2 correctly reflects the intended use of OIDC with UMA. And you have also correctly identified the “link” issue/question, which so far has only been addressed minimally in the UMA specs.

    What is missing from WF1 and WF2 is the fact that the clients (organizations or companies) from which Alice and Bob communicate with the AM must also be authenticated by the AM (through similar flows to the OP).

    Thus, Bob maybe accessing Alice’s medical records via Bob’s service provider (referred to as the Requester in the original UMA specs). The Requester is the Oauth client. For simplicity, lets say Bob was connecting to the AM and OP via So now in both WF1 and WF2, in addition to Alice and Bob needing to prove their true identities (via the OP-issued ID-tokens) the site must also prove its identity to the AM. So this is another OIDC flow that needs to be executed.

    This feature allows Alice to create a policy (at the AM) that states “it is OK for Bob to access my medical records but only through”. If Bob is accessing her data from another client (say, then Alice will not allow Bob to access her data.

    Why is important? The answer is Binding Obligations (and the broader legal operational rules of the ecosystem). When Alice gives access to both Bob and, she might have created her own “consent agreement” paragraph that puts limits on what Bob and can do with her medical data. This is the whole essence or core of *user* managed access.

    (PS. “Personal data is the new oil of the Internet”).


    1. Hi Thomas,

      You are absolutely right, and the client has to be authenticated as well. Inf act, I am capturing that portion in the subsequent post: Explicit Consent – Turning Internet Dog into Pavlov’s Dog ( ). In it, I am actually writing about the user set preference on the license for the use of his personal data. So, I am in a way, going even further than a “client authentication” but to a “third party certified request authentication”, which I need to document more.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.