[Openid-specs-heart] HEART Profiles - Authorization Server OAuth / UMA Clarification

[Justin Richer]

> On Dec 3, 2015, at 1:11 PM, Adrian Gropper <agropper at healthurl.com> wrote:
> 
> Inline...
> 
> On Thu, Dec 3, 2015 at 9:14 AM, Justin Richer <jricher at mit.edu <mailto:jricher at mit.edu>> wrote:
> Your three points below aren't related to each other -- specifically, the middle one about resource registration isn't related to key publication, at all.  
> 
> To the middle point: We state that the AS needs to support dynamic resource registration (and client registration, which is a prerequisite) and must allow the issuance of the corresponding PAT through a normal OAuth flow (as opposed to the magical "you get a token somehow we don't care" method in Core UMA). Such OAuth behavior is already profiled in the OAuth profile which profiles OAuth. If you think this can be clearer, please submit text making it so.
> 
> I will be happy to submit text for UMA Section 2 once I understand what user-delegated and non-delegated means and what the impact of RECOMMENDED vs. MUST will be in the context of resource registration.  

User delegated means an end user delegates access and is involved in the process. Non-delegated means the client is acting on its own behalf for that step. This text is saying the RO needs to set up the relationship between the RS and the AS, but the RqP doesn’t have to be present on the wire to set up the relationship between the client and AS. This is to patch around a technical limitation in UMA 1.0 that would otherwise require the RqP have an account of some type at the AS that was able to generate OAuth tokens. 

> 
> To the first and third points: It's stated in the OAuth profile that the AS's JWK Set must be able to be fetched over HTTPS and may be cached. It's up to the other side to do the fetching and caching, including any RS that needs to register sets. I don't believe that needs to be spelled out separately, but if you think it does, please submit text.
> 
> The most common objection by resource servers to dynamic registration of _any_ resource-owner-specified authorization server is that it is insecure to allow unverified clients to access the API that the resource server is responsible for. To mitigate this risk while also supporting the patient right of access requires access to separate security keys for each resource. (I think of this as "encryption at rest" applied to the API instead of the resource itself.) For this reason, I propose: 
> 
> At the beginning or end of Section 4.1 Discovery, add: "The resource server MUST allow for each protected resource to be associated with a different authorization server public key as negotiated for issuance of the PAT.”

There are no data encryption keys, so this doesn’t make any sense. The resources will require separate tokens and the clients have separate keys for authentication. This isn’t data encryption though — we’re not talking about direct and SMIME here. You’re confusing the technologies with each other.

 — Justin


> 
> Thanks,
> 
> Adrian
> 
>  
> 
> Thanks,
>  -- Justin
> 
> 
> On 12/3/2015 4:35 AM, Adrian Gropper wrote:
>> In section 4.1 Discovery of http://openid.bitbucket.org/HEART/openid-heart-oauth2.html <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html>, we have the requirement for each AS to have a public key ( jwks_uri The fully qualified URI of the server's public key in JWK Set <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC7517> [RFC7517] format ) This is good and clear.
>> 
>> Correspondingly, in the UMA profile  <http://openid.bitbucket.org/HEART/openid-heart-uma.html>http://openid.bitbucket.org/HEART/openid-heart-uma.html <http://openid.bitbucket.org/HEART/openid-heart-uma.html> I might expect a clearer reference to the resource registration aspects of UMA. As far as I can tell, this is mentioned in Section 2. Tokens as "It is RECOMMENDED that the PAT use a user-delegated mechanism for issuance and the AAT use a non-delegated method for issuance."
>> 
>> Does the HEART UMA profile require that a Resource Server MUST be capable of storing a separate AS public key (presumably the jwks_uri in OAuth 4.1) for every registered resource? If so, where is this stated and could it be made clearer?
>> 
>> Adrian
>> 
>> -- 
>> 
>> Adrian Gropper MD
>> 
>> PROTECT YOUR FUTURE - RESTORE Health Privacy!
>> HELP us fight for the right to control personal health data.
>> DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/>
>> 
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net <mailto:Openid-specs-heart at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
> 
> 
> 
> 
> -- 
> 
> Adrian Gropper MD
> 
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151203/b7bd89a1/attachment-0001.html>