<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>George, thanks for this update!</p>
<p>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.</p>
<p>I'm in support of option 2, that is:</p>
<ul>
<li>Reconsider the use of the ID token in the token exchange.<br>
<br>
</li>
<li>Specify how DPoP can be used to sender-constrain the
device_secret.</li>
</ul>
<p>These changes / updates need not be breaking. Why?</p>
<ul>
<li>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).<br>
<br>
</li>
<li>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.</li>
</ul>
<p>Of the two, I find DPoP the most important, in terms of security,
because it enables the binding of the device_secret.</p>
<p>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:</p>
<p><a class="moz-txt-link-freetext"
href="https://mailarchive.ietf.org/arch/msg/oauth/teCtQputdKH9pmZKjNiBOTQ-Jpo/"
moz-do-not-send="true">https://mailarchive.ietf.org/arch/msg/oauth/teCtQputdKH9pmZKjNiBOTQ-Jpo/</a></p>
<p>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.</p>
<pre class="moz-signature" cols="72">Vladimir Dzhuvinov</pre>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 30/10/2025 19:46, george--- via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:D207F603-9A9E-4AF8-B08C-05AB153D2B2B@practicalidentity.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hi,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>On the other hand, multiple IDP SaaS vendors and relying
parties have found the specification useful and have implemented
it. </div>
<div><br>
</div>
<div>So, I’d appreciate feedback on next steps. I see a couple of
options.</div>
<div>1. Take the current 2nd implementors draft to final</div>
<div>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.</div>
<div>3. Discard the specification completely</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
<div>
<div>George Fletcher</div>
<div>Identity Standards Architect</div>
<div>Practical Identity LLC</div>
<div><br>
</div>
<br class="Apple-interchange-newline">
</div>
<br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:Openid-specs-ab@lists.openid.net"
moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext"
href="https://lists.openid.net/mailman/listinfo/openid-specs-ab"
moz-do-not-send="true">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</body>
</html>