[Openid-specs-ab] [External Sender] Issue #2101: [Native App SSO] No prescriptive restriction on the authorization server to protect an actor-less token exchange (openid/connect)

[George Fletcher]

Hi Vivek,

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.

I'm happy to consider additional text if you feel it is necessary and you
have some to suggest.

Thanks,
George

On Wed, Dec 6, 2023 at 6:11 AM Vivek Shankar via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> New issue 2101: [Native App SSO] No prescriptive restriction on the
> authorization server to protect an actor-less token exchange
>
> https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues/2101/native-app-sso-no-prescriptive-restriction__;!!FrPt2g6CO4Wadw!Kp84p048yyMb-PiBjtF8suL8LFKHvVjNzghAjqRxNmcKMiz5fS30iSvK7KeRaG_n6JUrL8HGAj0iqxLrmf5CqQ0PlcFUPiop0HG9s5g$
>
> Vivek Shankar:
>
> Thank you for the OpenID Native App SSO spec. It solves a real-world
> problem. I have a proposed update to this spec.
>
>
>
> REF: [
> 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$
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
>
> https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!Kp84p048yyMb-PiBjtF8suL8LFKHvVjNzghAjqRxNmcKMiz5fS30iSvK7KeRaG_n6JUrL8HGAj0iqxLrmf5CqQ0PlcFUPiop8w1CnnA$
>

______________________________________________________________________



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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20231206/bef1d538/attachment.html>