<div dir="ltr">The RISC Profile was updated with the changes suggested by Dick. Attached.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">Marius</div></div>
<br><div class="gmail_quote">On Mon, Feb 26, 2018 at 6:55 PM, Hardt, Dick via Openid-specs-risc <span dir="ltr"><<a href="mailto:openid-specs-risc@lists.openid.net" target="_blank">openid-specs-risc@lists.openid.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_4621960947676909026WordSection1">
<p class="MsoNormal"><b><span style="font-size:11.0pt">Marius</span></b><span style="font-size:11.0pt">: I previously had asked that we use OAuth 2.0 as an assumption rather than OIDC. Phil’s comments highlighted issues with a deep assumption of OAuth 2.0,
 such as running an authorization server, that I am agreement with. I do think we want to specify how control plane APIs are authenticated. I do not think we want to specify how an access token is obtained.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Below I have suggested text for the sections that reference client id and OAuth specific language. I think we get interop at transport level by specifying RFC 6750. Allowing other mechanisms for token exchange
 besides the Client Credential Grant provides flexibility in how various receivers can obtain an access token. For example, it allows a 3 legged flow where the admin clicks through to enable a service provider to act on their behalf. It also allows a manual
 configuration where the access token is copy and pasted from a website into a service configuration.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Phil</span></b><span style="font-size:11.0pt">: do these changes address your concerns around OAuth 2.0?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">4.2.  Authorization<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">HTTP API calls from a receiver to a transmitter SHOULD be authorized<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">by providing an access token in the WWW-Authenticate HTTP header value per RFC 6750.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The receiver may obtain an access token using the Client Credential Grant [RFC 6749 <a href="https://tools.ietf.org/html/rfc6749#section-4.4" target="_blank">https://tools.ietf.org/html/<wbr>rfc6749#section-4.4</a>], or any other method suitable for the receiver and the transmitter.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">5.  Profile<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">This section is a profile of the following IETF SecEvent specifications:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">  <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Security Event Token (SET) <a href="https://datatracker.ietf.org/doc/draft-ietf-secevent-token/" target="_blank">https://datatracker.ietf.org/<wbr>doc/draft-ietf-secevent-token/</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">SET Token Delivery Using HTTP <a href="https://datatracker.ietf.org/doc/draft-ietf-secevent-delivery/" target="_blank">https://datatracker.ietf.org/<wbr>doc/draft-ietf-secevent-<wbr>delivery/</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">     <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">5.1.5.  The "aud" Claim<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The 'aud' claim MUST be a single value. It MAY be the client id if the receiver is an OAuth 2.0 client, or any other value that uniquely identifies the receiver to the transmitter.<u></u><u></u></span></p>
</div>
</div>

<br>______________________________<wbr>_________________<br>
Openid-specs-risc mailing list<br>
<a href="mailto:Openid-specs-risc@lists.openid.net">Openid-specs-risc@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-risc" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>risc</a><br>
<br></blockquote></div><br></div>