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

[george at practicalidentity.com]

Hi Vladimir,

Thank you for your feedback. Regarding the two possible additions to the spec, I think the DPoP binding makes a lot of sense and would have to have your thoughts on that direction based on your implementation experience.

Regarding the id_token, do you have any specific thoughts about how the id_token could be made optional?

Thanks,

George Fletcher
Identity Standards Architect
Practical Identity LLC



> On Nov 11, 2025, at 7:28 AM, Vladimir Dzhuvinov | Connect2id via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> 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 <mailto:Openid-specs-ab at lists.openid.net>
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> 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/20251121/e7ae0729/attachment.htm>