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

[Adrian Gropper]

Inline...

On Thu, Dec 3, 2015 at 9:14 AM, Justin Richer <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.

>
> 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."

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, 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 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/
>
>
> _______________________________________________
> Openid-specs-heart mailing listOpenid-specs-heart at lists.openid.nethttp://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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151203/2346582c/attachment.html>