[Openid-specs-ab] Next steps for the Native SSO for Mobile Apps specification

[Vladimir Dzhuvinov | Connect2id]

George, thanks for this update!

I voted for the 2nd implementers' draft. We have Native SSO in 
production use and I know it's being actively used in client code via 
the Nimbus OIDC SDK.

I'm in support of option 2, that is:

  * Reconsider the use of the ID token in the token exchange.

  * Specify how DPoP can be used to sender-constrain the device_secret.

These changes / updates need not be breaking. Why?

  * Use of the ID token can be made optional (though the API aspect of
    that may be problematic, as the ID token is passed via the
    subject_token parameter, which is required per RFC 8693).

  * DPoP for the device_secret can certainly be specified as optional,
    similar to how it's an optional extension for access tokens in 
    OAuth 2.0.

Of the two, I find DPoP the most important, in terms of security, 
because it enables the binding of the device_secret.

I recently got a helpful response in the OAuth WG how DPoP could work in 
a token exchange (RFC 8693) scenario. The conversation can be read here:

https://mailarchive.ietf.org/arch/msg/oauth/teCtQputdKH9pmZKjNiBOTQ-Jpo/

We are currently implementing DPoP for the device_secret in Native SSO, 
along the lines of the above formulated approach. I'll write here if we 
encounter any spec related issues.

Vladimir Dzhuvinov


On 30/10/2025 19:46, george--- via Openid-specs-ab wrote:
> Hi,
>
> We briefly discussed the Native SSO for Mobile Apps specification 
> today as part of the OpenID Connect working group call. The vote for 
> 2nd implementors draft completed successfully so this email is about 
> where we go from here.
>
> One objection was raised, during the working group call, to moving the 
> spec forward (more details in the minutes of today’s meeting) and if I 
> understand the objection correctly, it applies to the entire concept 
> of the spec not just a specific implementation aspect of it. In other 
> words, the objector doesn’t believe that the OpenID Foundation should 
> publish any document in this area. I appreciate the forthrightness and 
> clarity of the objection.
>
> On the other hand, multiple IDP SaaS vendors and relying parties have 
> found the specification useful and have implemented it.
>
> So, I’d appreciate feedback on next steps. I see a couple of options.
> 1. Take the current 2nd implementors draft to final
> 2. Work on significant updates to the current draft changing the way 
> it leverages id_tokens and potentially adding sender-constrained 
> aspects to the protocol. This would be a breaking change to the 
> current spec.
> 3. Discard the specification completely
>
> Personally, albeit I’m biased, and given that multiple parties have 
> implemented the specification, I believe it has value for our 
> industry. Being passed as a specification does not require any IDP or 
> vendor to implement the spec but it does provide at least one way to 
> provide this functionality. There may be other and better ways of 
> doing so but none have been brought forward and I believe that helping 
> developers do something sound is important (rather than the foundation 
> being silent).
>
> Therefore, my proposal is to tackle option 2 if there is sufficient 
> interest from the community to do the work. Otherwise, my proposal 
> will lean toward option 1.
>
> Thanks,
>
> George Fletcher
> Identity Standards Architect
> Practical Identity LLC
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20251111/c61796d2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4264 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20251111/c61796d2/attachment.p7s>