<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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. <div class=""><br class=""></div><div class="">The OAuth WG is starting to consider API registration, and that may be influenced by UMA.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class="">For access control you want the sub and possibly roll in the AT or available to the RS via introspection of the AT.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">John B.</div><div class=""><div><blockquote type="cite" class=""><div class="">On Dec 8, 2015, at 11:52 AM, Cal Heldenbrand <<a href="mailto:cal@fbsdata.com" class="">cal@fbsdata.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">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: <a href="https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html" class="">https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html</a><br class=""><br class=""></div>(From this list here: <span class=""><a href="https://kantarainitiative.org/confluence/display/uma/Specifications+and+Auxiliary+Documents?src=breadcrumbs-parent" class="">Specifications and Auxiliary Documents</a></span>)<br class=""><br class=""></div>I still need to take the time to thoroughly study this, but the Introduction seems right up your alley.<br class=""></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"><br class="">---------------------------------------------------------------<br class="">Cal Heldenbrand<br class=""> Web Operations at FBS<br class=""> Creators of <a href="http://flexmls.com/" target="_blank" class="">flexmls</a>® and <a href="http://sparkplatform.com/" target="_blank" class="">Spark Platform</a><br class=""> <a href="mailto:cal@fbsdata.com" target="_blank" class="">cal@fbsdata.com</a></div></div>
<br class=""><div class="gmail_quote">On Mon, Dec 7, 2015 at 11:15 PM, Steve Garing <span dir="ltr" class=""><<a href="mailto:steve.garing@guvera.com" target="_blank" class="">steve.garing@guvera.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Thanks Cal.<div class=""><br class=""></div><div class="">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?</div><div class="">Good old wikipedia explains is better than I can with my limited understanding <a href="https://en.wikipedia.org/wiki/User-Managed_Access" target="_blank" class="">UMA</a>. So this wouldn’t actually let the clients know if the user has ROLE_USER or ROLE_ADMIN etc from what I understand.</div><div class=""><br class=""></div><div class="">Adding a custom claim seems to be the way to go I think</div><div class=""><br class=""></div></div><div class="gmail_extra"><div class=""><div class="h5"><br class=""><div class="gmail_quote">On Tue, Dec 8, 2015 at 12:43 AM, Cal Heldenbrand <span dir="ltr" class=""><<a href="mailto:cal@fbsdata.com" target="_blank" class="">cal@fbsdata.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class=""><div class="">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.<br class=""><br class=""></div>However, section <a href="http://openid.net/specs/openid-connect-core-1_0.html#AdditionalClaims" target="_blank" class="">5.1.2</a> states that you can add any custom claims that you'd like. Pick a unique name like "mitre_scopes" and add it to your <a href="http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata" target="_blank" class="">discovery document's</a> <span style="font-family:monospace,monospace" class="">claims_supported</span> property. Then expose that claim as an array over ID Tokens/UserInfo as normal.<br class=""><br class=""></div>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. ;-)<br class=""><div class=""><div class=""><div class=""><div class=""><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="">Good luck!<br class=""><br class=""></div><div class="">--Cal<br class=""><br class=""></div><div class="">---------------------------------------------------------------<br class="">Cal Heldenbrand<br class=""> Web Operations at FBS<br class=""> Creators of <a href="http://flexmls.com/" target="_blank" class="">flexmls</a>® and <a href="http://sparkplatform.com/" target="_blank" class="">Spark Platform</a><br class=""> <a href="mailto:cal@fbsdata.com" target="_blank" class="">cal@fbsdata.com</a></div></div>
<br class=""><div class="gmail_quote"><div class=""><div class="">On Mon, Dec 7, 2015 at 4:42 AM, Steve Garing <span dir="ltr" class=""><<a href="mailto:steve.garing@guvera.com" target="_blank" class="">steve.garing@guvera.com</a>></span> wrote:<br class=""></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div style="font-size:13px" class="">Hi,</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">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.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">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?</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">Thanks,</div><div style="font-size:13px" class="">Steve</div></div></div>
</div>
<br class=""></div></div>_______________________________________________<br class="">
general mailing list<br class="">
<a href="mailto:general@lists.openid.net" target="_blank" class="">general@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-general" rel="noreferrer" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-general</a><br class="">
<br class=""></blockquote></div><br class=""></div></div></div></div></div></div>
</blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div></div></div>-- <br class=""><div class=""><div dir="ltr" class=""><table style="font-family: Times;" cellpadding="0" cellspacing="0" width="100%" class=""><tbody class=""><tr class=""><td style="padding:0px" align="left" valign="top" class=""><table cellpadding="0" cellspacing="0" width="100%" class=""><tbody class=""><tr class=""><td style="padding:10px 0px 0px;font-family:Helvetica,Arial,sans-serif;font-size:10px;color:rgb(119,119,119)" align="left" valign="top" width="100%" class=""><b class="">Steve Garing</b><br class="">Senior Software Engineer<br class=""></td></tr><tr class=""><td style="padding:10px 0px 0px;font-family:Helvetica,Arial,sans-serif;font-size:10px;color:rgb(119,119,119)" align="left" valign="top" width="100%" class=""><strong class="">Guvera Australia Pty Ltd.</strong><br class="">Suite 903, Level 9, The Rocket<br class="">203 Robina Town Centre Drive<br class="">Robina, QLD, 4226<br class="">Australia<br class="">PO Box 4232 Robina TC QLD 4230<br class=""></td></tr><tr class=""><td style="padding:10px 0px 0px;font-family:Helvetica,Arial,sans-serif;font-size:10px;color:rgb(119,119,119)" align="left" valign="top" width="100%" class=""><strong style="padding:10px 0px 0px" class="">Phone </strong><span style="padding:10px 0px 0px" class=""><a href="tel:%2B61%20%280%29%207%205578%208987" value="+61755788987" target="_blank" class="">+61 (0) 7 5578 8987</a></span><br class=""><strong style="padding:10px 0px 0px" class=""><br class="">Email </strong><span style="padding:10px 0px 0px" class=""><a href="mailto:kim.bennett@guvera.com" style="padding:10px 0px 0px;color:rgb(119,119,119)" target="_blank" class="">s</a><a href="mailto:teve.garing@guvera.com" target="_blank" class="">teve.garing@guvera.com</a></span><br class=""><strong style="padding:10px 0px 0px" class="">Web </strong><span style="padding:10px 0px 0px" class=""></span><a href="https://www.guvera.com/" style="padding:10px 0px 0px;color:rgb(119,119,119)" target="_blank" class="">www.guvera.com</a><br class=""><br class=""><br class=""><br class=""></td></tr></tbody></table></td></tr></tbody></table><span style="font-family: Times; font-size: inherit;" class=""><img src="https://www.guvera.com/d1/images/email-logo.png" height="120" width="120" class=""></span><br class=""></div></div>
</div>
</blockquote></div><br class=""></div>
_______________________________________________<br class="">general mailing list<br class=""><a href="mailto:general@lists.openid.net" class="">general@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-general<br class=""></div></blockquote></div><br class=""></div></body></html>