<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #1A1A1A;text-align: left" dir="ltr">
Thanks George. <div><br></div><div>I'd also like to see some clarification in this document if the authorize endpoint is required to be used. </div><div><br></div><div>What I mean is that what seems most important in this spec is the results from the token endpoint, and there are different ways a client might get results from the token endpoint (and not just by using the authorize endpoint). For example, the up and coming "OAuth 2.0 for First Party Clients" defines a way for a client to obtains results from the token endpoint. Could that flow (without using the authorize endpoint) then get a "device_secret", and then use that in another client app or on a different device to login via "<span style="font-size: 10pt">OpenID Connect Native SSO for Mobile Apps"?</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">Thanks.</span></div><div><br></div><div><div class="mb_sig">-Brock<div><br></div></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">On 11/27/2024 8:55:44 AM, George Fletcher via Openid-specs-ab <openid-specs-ab@lists.openid.net> wrote:</p><div style="font-family:Arial,Helvetica,sans-serif"><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">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"><u></u>
<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">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">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">
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">
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">
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">
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">
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">
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">
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">
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">
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">
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">
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">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">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"><span style="font-size: 10pt">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.</span></span></i><br>
<fieldset></fieldset>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">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">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">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">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><span style="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.</span><br><br><table border="0" cellspacing="0" cellpadding="0" width="100%" height="30">
<tbody><tr>
</tr>
</tbody></table><br>
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab@lists.openid.net
https://lists.openid.net/mailman/listinfo/openid-specs-ab
</div></blockquote>
</div></div>