[OpenID] Return Authorities to Client

[Cal Heldenbrand]

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

(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

On Mon, Dec 7, 2015 at 11:15 PM, Steve Garing <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> 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
>>
>> On Mon, Dec 7, 2015 at 4:42 AM, Steve Garing <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
>>> 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
>
> *Email *s <kim.bennett at guvera.com>teve.garing at guvera.com
> *Web *www.guvera.com
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20151208/82ac8a8a/attachment.html>