<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks George.</p>
<p>The credential that does the magic of Native SSO is the
device_secret. It's an opaque token, so the OP is free to include
the user identity and all sorts of device session related info in
it, making the ID token redundant.</p>
<p>If we remove the ID token from the token exchange grant:</p>
<ul>
<li>The flow for client apps and the IdP is simplified<br>
<br>
</li>
<li>The client apps only need to store the device_secret on the
key chain. An ID token is no longer shared between them.<br>
<br>
</li>
<li>We save the IdP the following:</li>
</ul>
<blockquote>
<ul>
<li>Validating the ID token with an "exp" and "aud" exception</li>
<li>Checking the ID token "ds_hash" against the device_secret</li>
<li>Decrypting the ID token "sub" (for pairwise IDs)</li>
<li>Checking the ID token "sub" against the device_secret
subject<br>
<br>
</li>
<li>Additionally, when the device_secret is updated, this
obliging the IdP to issue a matching ID token for it<br>
</li>
</ul>
</blockquote>
<ul>
<li>Use of the ID token as an authorisation can be considered an
anti-pattern<br>
<br>
</li>
<li>The ID token may include personal details. When used at the
token endpoint, because it's usually a signed JWT and not an
opaque credential, these details may end up in the server logs.<br>
</li>
</ul>
<p><br>
</p>
<pre class="moz-signature" cols="72">Vladimir Dzhuvinov</pre>
<div class="moz-cite-prefix">On 27/11/2024 15:55, George Fletcher
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJnLd9JHgHvMX8a7YgR1DTaV33P6dXz-moUmmeHqr_CjHxZNZA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">So I'd like to open the topic of updating the
spec to not require the id_token or at least drastically
reduce the dependence on the id_token in the flows.<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'm very happy to work on those changes and produce an
updated draft. I know some feel we don't need the spec at
all but for those who've implemented it, or are interested
in the work, is this a good path to pursue?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>George</div>
</div>
<br>
<div class="gmail_quote" style="">
<div dir="ltr" class="gmail_attr">On Tue, Nov 19, 2024 at
3:17 PM Vladimir Dzhuvinov / Connect2id via Openid-specs-ab
<<a href="mailto:openid-specs-ab@lists.openid.net"
moz-do-not-send="true" class="moz-txt-link-freetext">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">
<div>
<p>When we implemented Native SSO we found the ID token to
be redundant in the token exchange step.</p>
<p>The device_secret "token" can be made to include
everything that the ID token has, plus more if
necessary. Thus the device_secret was entirely
sufficient to determine the SSO subject and what other
properties were necessary for the native session, such
as the device session expiration and the ACR of the
original user authentication.</p>
<p>I tend to agree that sometimes customers can't be
demanding enough with specs that bring cool new
features. And just the opposite when the spec does
nothing significant, other than going to markedly
improve their security, long term. I just said to
myself, I some of them are reading this.</p>
<p>I think the self-help strategy to stay sane at this job
- and that includes on the customer front - is to
produce specs that are consistently & conceptually
simple, easy to implement and fit the landscape of
surrounding specs. This is what feels bad and
demoralises - having to implement specs that conflict
with one another or break previous guidance. Then the
acrobatics to explain and justify that to customers.<br>
</p>
<p><br>
</p>
<pre cols="72">Vladimir Dzhuvinov</pre>
<div>On 19/11/2024 19:19, Brian Campbell via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Finding things in the archives is not
easy (for me anyway) but here's one historical account
of my prior push-back on progressing Native SSO <a
href="https://urldefense.com/v3/__https://lists.openid.net/pipermail/openid-specs-ab/2022-September/009376.html__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIwOP8F1E$"
target="_blank" moz-do-not-send="true">https://lists.openid.net/pipermail/openid-specs-ab/2022-September/009376.html</a>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Nov 18, 2024
at 5:53 PM Michael Jones via Openid-specs-ab <<a
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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">
<div>
<div lang="EN-US">
<div>
<p class="MsoNormal">Spec Call Notes 18-Nov-24</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">George Fletcher</p>
<p class="MsoNormal">Nat Sakimura</p>
<p class="MsoNormal">Mike Jones</p>
<p class="MsoNormal">Brian Campbell</p>
<p class="MsoNormal">David Waite</p>
<p class="MsoNormal">Tom Jones</p>
<p class="MsoNormal">Aaron Parecki</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Native SSO spec</p>
<p class="MsoNormal"> <a
href="https://urldefense.com/v3/__https://bitbucket.org/openid/connect/pull-requests/742__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIQtja1Hk$"
target="_blank" moz-do-not-send="true">
https://bitbucket.org/openid/connect/pull-requests/742</a></p>
<p class="MsoNormal">
Mike will review and merge if it looks OK</p>
<p class="MsoNormal"> There are
8 open issues for Native SSO - 3 to be
closed by the PR above</p>
<p class="MsoNormal"> Brian
questioned whether we should be taking this
to final or not</p>
<p class="MsoNormal">
Given that it may not be the best practice
for doing this</p>
<p class="MsoNormal">
He said that we could make it a blog post</p>
<p class="MsoNormal"> George
asked if there is another best practice that
we should document instead</p>
<p class="MsoNormal">
He observed that no one has proposed a
better way</p>
<p class="MsoNormal"> Mike said
that Okta has implemented, so we should
involve them</p>
<p class="MsoNormal">
Yahoo has implemented it, Vladimir has
implemented it</p>
<p class="MsoNormal"> George
said that there's value in documenting these
things</p>
<p class="MsoNormal">
He wanted the working group to weigh in to
improve it, which they have</p>
<p class="MsoNormal"> Mike
observed that we're also doing first-party
app work in the OAuth WG</p>
<p class="MsoNormal"> (Aaron
joined the call at this point)</p>
<p class="MsoNormal"> Mike
asked about Okta implementing the Native SSO
spec</p>
<p class="MsoNormal">
George said that Okta had extended it for a
cross-device case in a prototype</p>
<p class="MsoNormal">
Aaron said that it's available as an API</p>
<p class="MsoNormal">
<a
href="https://urldefense.com/v3/__https://developer.okta.com/docs/guides/configure-native-sso/main/__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIKkdTIj8$"
target="_blank" moz-do-not-send="true">
https://developer.okta.com/docs/guides/configure-native-sso/main/</a></p>
<p class="MsoNormal"> Aaron
said that Google has deployed a similar
thing</p>
<p class="MsoNormal">
George said that he wrote this down so
others could understand how to achieve what
Google has</p>
<p class="MsoNormal"> Brian
really dislikes the use of ID Tokens as
hints and with different validation rules</p>
<p class="MsoNormal"> Brian
said that that a sometimes problem with
publishing specs is customers will see it
and ask for it to be implemented</p>
<p class="MsoNormal">
We should be cognizant of that</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Mobile work</p>
<p class="MsoNormal"> George
mused about whether we want to do any
additional mobile-related work</p>
<p class="MsoNormal"> Mike
asked what the MODRNA WG is doing now</p>
<p class="MsoNormal">
People on the call didn't know</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Bitbucket Issues</p>
<p class="MsoNormal"> <a
href="https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues?status=new&status=open&status=submitted&is_spam=!spam__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIl9tvU48$"
target="_blank" moz-do-not-send="true">
https://bitbucket.org/openid/connect/issues?status=new&status=open&status=submitted&is_spam=!spam</a></p>
<p class="MsoNormal"> No new
issues</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Working Group GitHub
Repositories</p>
<p class="MsoNormal"> We now
have four working group GitHub repositories:</p>
<p class="MsoNormal"> 1. <a
href="https://urldefense.com/v3/__https://github.com/openid/federation__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kICqMvs5A$"
target="_blank" moz-do-not-send="true">
https://github.com/openid/federation</a></p>
<p class="MsoNormal"> 2. <a
href="https://urldefense.com/v3/__https://github.com/openid/federation-extended-listing__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kI5gKr-Ao$"
target="_blank" moz-do-not-send="true">
https://github.com/openid/federation-extended-listing</a></p>
<p class="MsoNormal">
No issues or PRs</p>
<p class="MsoNormal">
Implementations requested</p>
<p class="MsoNormal"> 3. <a
href="https://urldefense.com/v3/__https://github.com/openid/federation-wallet/__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIpxyRY3A$"
target="_blank" moz-do-not-send="true">
https://github.com/openid/federation-wallet/</a></p>
<p class="MsoNormal">
14 open issues</p>
<p class="MsoNormal">
Many of the early ones record things that
were in pre-adopted versions of the spec</p>
<p class="MsoNormal">
<a
href="https://urldefense.com/v3/__https://github.com/openid/federation-wallet/issues/39__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kITErbkb8$"
target="_blank" moz-do-not-send="true">
https://github.com/openid/federation-wallet/issues/39</a> Authorized
Credential within OpenID4VP metadata using
Duckle</p>
<p class="MsoNormal">
Mike will review</p>
<p class="MsoNormal">
<a
href="https://urldefense.com/v3/__https://github.com/openid/federation-wallet/issues/40__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIv4NA8x8$"
target="_blank" moz-do-not-send="true">
https://github.com/openid/federation-wallet/issues/40</a> Trust Marks
examples</p>
<p class="MsoNormal">
The examples seem reasonable</p>
<p class="MsoNormal">
<a
href="https://urldefense.com/v3/__https://github.com/openid/federation-wallet/issues/41__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIrMFRf9I$"
target="_blank" moz-do-not-send="true">
https://github.com/openid/federation-wallet/issues/41</a> Complex Trust
Marks examples</p>
<p class="MsoNormal">
What's the motivation for these examples?</p>
<p class="MsoNormal">
<a
href="https://urldefense.com/v3/__https://github.com/openid/federation-wallet/issues/42__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIjUMqFGc$"
target="_blank" moz-do-not-send="true">
https://github.com/openid/federation-wallet/issues/42</a> Trust Mark
with Intended Usage </p>
<p class="MsoNormal">
ditto</p>
<p class="MsoNormal"> 4. <a
href="https://urldefense.com/v3/__https://github.com/openid/rp-metadata-choices__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kIGYgdnsI$"
target="_blank" moz-do-not-send="true">
https://github.com/openid/rp-metadata-choices</a></p>
<p class="MsoNormal">
No issues or PRs</p>
<p class="MsoNormal">
Mike knows of work to do due to the
discussion on the list after the spec was
contributed</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> Nat
pointed out that we need to update the
repository page for the WG to list all the
repositories</p>
<p class="MsoNormal">
Mike agreed to take the action to do that</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">OpenID4VP</p>
<p class="MsoNormal"> It's
currently in the 45-day foundation-wide
review as a proposed Implementer's Draft</p>
<p class="MsoNormal"> Tom asked
about user consent with credential
presentation</p>
<p class="MsoNormal"> Mike
suggested that if he has objections to the
spec that he put them in issues</p>
<p class="MsoNormal">
Then the objections are actionable</p>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-ab@lists.openid.net</a><br>
<a
href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kI7qkZS8I$"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div>
</blockquote>
</div>
<br>
<i
style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span
style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font
size="2">CONFIDENTIALITY NOTICE: This email may
contain confidential and privileged material for
the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others
is strictly prohibited. If you have received this
communication in error, please notify the sender
immediately by e-mail and delete the message and
any file attachments from your computer. Thank
you.</font></span></i><br>
<fieldset></fieldset>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">Openid-specs-ab@lists.openid.net</a>
<a
href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kI7qkZS8I$"
target="_blank" moz-do-not-send="true">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-ab@lists.openid.net</a><br>
<a
href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kI7qkZS8I$"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!IZf3UY-vBkVT-mEDYe6n1IUKwyjYi-VeluMtz_F5Lzadweo4tTxROsj8r5bqiQp7AnKDl_7D3ky0JFu68e27qHMC0oeRX9kI7qkZS8I$</a>
<br>
</blockquote>
</div>
</div>
<hr><br>
<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><br>
<br>
<table width="100%" height="30" cellspacing="0" cellpadding="0"
border="0">
<tbody>
<tr>
</tr>
</tbody>
</table>
<br>
</blockquote>
</body>
</html>