<div dir="ltr"><div dir="ltr">Hi Vivek,<input name="virtru-metadata" type="hidden" value="{"email-policy":{"disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"expandedWatermarking":false,"expires":false,"sms":false,"expirationNum":1,"expirationUnit":"days","isManaged":false,"persistentProtection":false},"attachments":{},"compose-id":"1","compose-window":{"secure":false}}"><div><br></div><div>I agree that RFC 8693 does not make the actor_token REQUIRED. However section 4.1 of the implementor's draft profiles RFC 8693 and makes the actor_token mandatory (REQUIRED) for the Native SSO spec.</div><div><br></div><div>I'm happy to consider additional text if you feel it is necessary and you have some to suggest.</div><div><br></div><div>Thanks,</div><div>George</div></div><br><div class="gmail_quote" style=""><div dir="ltr" class="gmail_attr">On Wed, Dec 6, 2023 at 6:11 AM Vivek Shankar via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">New issue 2101: [Native App SSO] No prescriptive restriction on the authorization server to protect an actor-less token exchange<br>
<a href="https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues/2101/native-app-sso-no-prescriptive-restriction__;!!FrPt2g6CO4Wadw!Kp84p048yyMb-PiBjtF8suL8LFKHvVjNzghAjqRxNmcKMiz5fS30iSvK7KeRaG_n6JUrL8HGAj0iqxLrmf5CqQ0PlcFUPiop0HG9s5g$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues/2101/native-app-sso-no-prescriptive-restriction__;!!FrPt2g6CO4Wadw!Kp84p048yyMb-PiBjtF8suL8LFKHvVjNzghAjqRxNmcKMiz5fS30iSvK7KeRaG_n6JUrL8HGAj0iqxLrmf5CqQ0PlcFUPiop0HG9s5g$</a> <br>
<br>
Vivek Shankar:<br>
<br>
Thank you for the OpenID Native App SSO spec. It solves a real-world problem. I have a proposed update to this spec.<br>
<br>
<br>
<br>
REF: [<a href="https://urldefense.com/v3/__https://openid.net/specs/openid-connect-native-sso-1*5C_0-ID1.html*section-4.3*(https:/*openid.net/specs/openid-connect-native-sso-1_0-ID1.html*section-4.3)__;JSNdLyM!!FrPt2g6CO4Wadw!Kp84p048yyMb-PiBjtF8suL8LFKHvVjNzghAjqRxNmcKMiz5fS30iSvK7KeRaG_n6JUrL8HGAj0iqxLrmf5CqQ0PlcFUPiopeRIbClA$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://openid.net/specs/openid-connect-native-sso-1*5C_0-ID1.html*section-4.3*(https:/*openid.net/specs/openid-connect-native-sso-1_0-ID1.html*section-4.3)__;JSNdLyM!!FrPt2g6CO4Wadw!Kp84p048yyMb-PiBjtF8suL8LFKHvVjNzghAjqRxNmcKMiz5fS30iSvK7KeRaG_n6JUrL8HGAj0iqxLrmf5CqQ0PlcFUPiopeRIbClA$</a> <br>
<br>
The native app SSO flow’s token exchange profile expects the actor token is going to somehow be mandatory. However, OAuth 2.0 token exchange does not mandate that the actor token is required. Should this perhaps be prescriptive? For example, if the `ds_hash` claim is present in the subject token, the corresponding device\_secret must be provided as an actor token. <br>
<br>
<br>
<br>
Given the spec hinges on the pairing of the id\_token and the device\_secret for the token exchange profile, this seems important to prescribe. This is necessary, IMHO, to avoid badly written clients just using the id\_token to obtain an access token, which is the ultimate goal for those client apps.<br>
<br>
<br>
<br>
Failing to have something like this in place forces OPs to come up with their own bespoke enforcement. Not having some form of enforcement, IMO, can cause inadvertent exposure in a real implementation.<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Kp84p048yyMb-PiBjtF8suL8LFKHvVjNzghAjqRxNmcKMiz5fS30iSvK7KeRaG_n6JUrL8HGAj0iqxLrmf5CqQ0PlcFUPiop8w1CnnA$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Kp84p048yyMb-PiBjtF8suL8LFKHvVjNzghAjqRxNmcKMiz5fS30iSvK7KeRaG_n6JUrL8HGAj0iqxLrmf5CqQ0PlcFUPiop8w1CnnA$</a> <br>
</blockquote></div></div>

<HR><table border="0" cellspacing="0" cellpadding="0" width="100%" height="30"><BR>
<tr><BR>
<font color="#404040">The information contained in this e-mail may be confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.</font></td><BR>
</tr><BR>
</table><BR>