[mitreid-connect] Enforcing some attributes during Dynamic Client Registration

[Luiz Omori]

Actually, thinking about it, protecting the Registration endpoint, either by the Initial Access Token or enforced Software Statement, has some nasty side effects for us. That enforcement would mean that the client app would have to either be distributed with that or somehow obtained at installation time? Our use case is for generic client apps calling FHIR (https://www.hl7.org/fhir/index.html) implemented at multiple disconnected healthcare providers. This is a highly regulated environment so we would have a hard time either way with Dynamic Registration:


1.       Open: not sure if the companies currently involved with this API are ready to allow any FHIR application to start requesting data, EVEN if we consider that ultimately the user has to approve such app to access her data. I know the HEART guys will have a field day here... This is just my personal view based on some informal internal discussions.

2.       Protected: implementation issues described above.

Regards,
Luiz

From: Justin Richer <jricher at mit.edu>
Date: Wednesday, July 12, 2017 at 11:44 AM
To: Luiz Omori <luiz.omori at duke.edu>
Cc: "mitreid-connect at mit.edu" <mitreid-connect at mit.edu>
Subject: Re: [mitreid-connect] Enforcing some attributes during Dynamic Client Registration

You are correct that currently nothing in the server requires a software statement. That could be added with a fairly simple configuration switch if you wanted to try that and send in a pull request against that class. At the very least, feel free to file an issue to make it optionally required.

 — Justin

On Jul 11, 2017, at 2:29 PM, Luiz Omori <luiz.omori at duke.edu<mailto:luiz.omori at duke.edu>> wrote:

Hi,

We want to enforce some attributes for Dynamic Client Registration. The following statement can be found in the section 12.3.3 Software Statements of the book OAuth2 in Action:

“But what if we had a way to present client metadata to the authorization server in a way that the authorization server could verify that it’s coming from a trusted party? With such a mechanism, the authorization server would be able to lock down certain metadata attributes in clients and have a higher assurance that the metadata is valid. The OAuth dynamic registration protocol provides such a mechanism in the software statement.”

All seems to fit well to our requirement however I took a look at the DynamicClientRegistrationEndpoint.java implementation and I’m a bit confused on how this could be enforced. Sure, if an Software Statement is present then its signature will be verified and its claims will take precedence over any duplicated ones presented by the caller. However, the caller can simply omit that Software Statement as its presence is optional? Or am I looking at the wrong module?

Regards,
Luiz
_______________________________________________
mitreid-connect mailing list
mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>
http://mailman.mit.edu/mailman/listinfo/mitreid-connect<https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.mit.edu_mailman_listinfo_mitreid-2Dconnect&d=DwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=R6m41WT3w_KtulQAsSIxc_C2mwuKoWSycEMpss0QQJA&m=skAglWDliXkQSuk0ya6i3Wt0YAtLYALFGcavh7tbsD4&s=JJq-urNj5B1oKs5QAVMaUN2BFg3SuJpjfYzxd4struM&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20170712/56ad89f2/attachment.html