[OpenID] Return Authorities to Client

Tue Dec 8 15:36:08 UTC 2015

That is more about having an external RS register it’s resources at the AS.   It is probably overkill for a single attribute in a related RS.   

The OAuth WG is starting to consider API registration, and that may be influenced by UMA.

However I think the simplest thing is to decide the attribute is an administrative one and release it in the id_token for your own registered clients.

This is a attribute for the client to use to configure the UI, and not a scope that the RS is using for access control.  
For access control you want the sub and possibly roll in the AT or available to the RS via introspection of the AT.

UMA allows you to outsource all of the access control back to the AS where the AS makes all the policy decisions, and the RS gets a ACL with R/W/C/D permissions for the URI resources from a more formal REST perspective.  

John B.
> On Dec 8, 2015, at 11:52 AM, Cal Heldenbrand <cal at fbsdata.com> wrote:
> 
> I think you're right, that the core UMA specs are about real time access to an API using a deferred consent action by a human.  However, I think this side spec might be close to what you're attempting to do:  https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html <https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html>
> 
> (From this list here: Specifications and Auxiliary Documents <https://kantarainitiative.org/confluence/display/uma/Specifications+and+Auxiliary+Documents?src=breadcrumbs-parent>)
> 
> I still need to take the time to thoroughly study this, but the Introduction seems right up your alley.
> 
> 
> ---------------------------------------------------------------
> Cal Heldenbrand
>    Web Operations at FBS
>    Creators of flexmls <http://flexmls.com/>® and Spark Platform <http://sparkplatform.com/>
>    cal at fbsdata.com <mailto:cal at fbsdata.com>
> On Mon, Dec 7, 2015 at 11:15 PM, Steve Garing <steve.garing at guvera.com <mailto:steve.garing at guvera.com>> wrote:
> Thanks Cal.
> 
> Isn’t UMA an interface for allowing the Resource Owner to grant permissions to resources without the owners need to be present at the time of request?
> Good old wikipedia explains is better than I can with my limited understanding UMA <https://en.wikipedia.org/wiki/User-Managed_Access>.  So this wouldn’t actually let the clients know if the user has ROLE_USER or ROLE_ADMIN etc from what I understand.
> 
> Adding a custom claim seems to be the way to go I think
> 
> 
> On Tue, Dec 8, 2015 at 12:43 AM, Cal Heldenbrand <cal at fbsdata.com <mailto:cal at fbsdata.com>> wrote:
> I'll take a crack at this, even though I'm probably not the most qualified to do so.  OAuth2 scopes are outside the specification scope of OpenID Connect.
> 
> However, section 5.1.2 <http://openid.net/specs/openid-connect-core-1_0.html#AdditionalClaims> states that you can add any custom claims that you'd like.  Pick a unique name like "mitre_scopes" and add it to your discovery document's <http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata> claims_supported property.  Then expose that claim as an array over ID Tokens/UserInfo as normal.
> 
> This is non-standard though, so it doesn't fully answer your question.  You might want to take a look at User-Managed Access (UMA) which is a standard way of conveying authorization / access control between many parties.  I'm in my beginning phases of researching UMA, so don't take my advice too heavily.  ;-)
> 
> Good luck!
> 
> --Cal
> 
> ---------------------------------------------------------------
> Cal Heldenbrand
>    Web Operations at FBS
>    Creators of flexmls <http://flexmls.com/>® and Spark Platform <http://sparkplatform.com/>
>    cal at fbsdata.com <mailto:cal at fbsdata.com>
> On Mon, Dec 7, 2015 at 4:42 AM, Steve Garing <steve.garing at guvera.com <mailto:steve.garing at guvera.com>> wrote:
> Hi,
> 
> Is there a standard way to return the authorities to a client?  I haven’t been able to get the authorities returned via standard functionality in the MITREid Connect project and we’d like the clients to have visibility of a users role to determine some client side functionality.
> 
> Would it correct to think that the clients can request and extra scope like ‘authorities’ and then provide the authorities in the id_token and from the userinfo endpoint?
> 
> Thanks,
> Steve
> 
> _______________________________________________
> general mailing list
> general at lists.openid.net <mailto:general at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-general <http://lists.openid.net/mailman/listinfo/openid-general>
> 
> 
> 
> 
> 
> -- 
> Steve Garing
> Senior Software Engineer
> Guvera Australia Pty Ltd.
> Suite 903, Level 9, The Rocket
> 203 Robina Town Centre Drive
> Robina, QLD, 4226
> Australia
> PO Box 4232 Robina TC QLD 4230
> Phone +61 (0) 7 5578 8987 <tel:%2B61%20%280%29%207%205578%208987>
> 
> Email s <mailto:kim.bennett at guvera.com>teve.garing at guvera.com <mailto:teve.garing at guvera.com>
> Web www.guvera.com <https://www.guvera.com/>
> 
> 
> 
> 
> 
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20151208/512b7abd/attachment.html>