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;

Assumption:

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.

OK?