<div dir="ltr">Yeah, that definitely seems to meet the criteria, especially with the no user interaction redirect.<br><br>I haven't been following as closely recently, but have there been discussions on allowing refresh tokens for SPAs if they're sender-constrained? I.e. if you're using code/PKCE + DPoP and the DPoP private key is marked non-extractable, it seems to address some security concerns around refresh tokens in the browser. The idea here being to side-step this new webkit behavior by reducing (or maybe eliminating?) the need to redirect to the OP for any flow where we don't have explicit user interactions in the SPA first.<br><br>If the SPA does get into a case where it needs to redirect to the OP, and it has storage that must-not-be-cleared (i.e. the DCR clientId), it does feel like its no longer safe to do this without user interaction - the SPA would have to present a button to redirect rather than doing it automatically. Similar to how the earlier ITP2 changes affected the SPA hidden iframe token renewal flows - there was no longer a way to unlock third-party session cookies without a user interaction to use the new storage access apis.<br><div><br></div><div>/r</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 5, 2019 at 6:26 PM George Fletcher <<a href="mailto:gffletch@aol.com">gffletch@aol.com</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 bgcolor="#FFFFFF">
<font face="Helvetica, Arial, sans-serif">Thanks so much for your
response.</font><br>
<br>
So here is how I was thinking of using Dynamic Client Registration
(DCR) for a browser based app. Think something more akin to a Single
Page App. The App loads in the browser. The browser uses the Crypto
JS library to create a pub/priv key pair. The App uses Dynamic
Client Registration to register the public key. Now the browser has
a unique client_id to use for any future calls. In this context, the
App would need to store the private key in localStorage/indexDB. If
localStorage is cleared then the private key is gone and the DCR is
pointless. Note that in this context the private key could also be
used for sender-constrained tokens with DPOP as an example.<br>
<br>
In regards to user-interaction... in some cases where user
authentication is required, the user is redirected without any user
interaction because they are not logged in. In this context the
local storage would be cleared and the calls to the token endpoint
would fail (as you outlined below). Think entering <a href="http://mail.google.com" target="_blank">mail.google.com</a>
as the URL in the browser:)<br>
<br>
Thanks,<br>
George<br>
<br>
<div class="gmail-m_-8428105427371736601moz-cite-prefix">On 6/4/19 11:06 AM, Reman Child wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi George,<br>
<br>
Can you explain more about why you think this breaks Dynamic
Client Registration in the browser?<br>
<br>
Looking at the code [1], it seems like this should only affect
the RP in these flows and not the OP. If I'm reading it right,
this is the expected behavior:<br>
- RP initiates some flow against the OP through a redirect<br>
- OP is prevalent (category where this and other ITP2 behavior
kicks in)<br>
- OP redirects back to RP with link decoration<br>
- RP localStorage/indexedDB is cleared<br>
<br>
So, an affected flow could be something like the new proposal to
use PKCE & auth code for browser apps [2] if it uses
localStorage/etc for the code_verifier:<br>
- RP stores code_verifier in localStorage, initiates
authorization request<br>
- OP is prevalent, redirects back to RP with link decoration
(i.e. code, etc)<br>
- Safari clears localStorage i.e. code_verifier, RP can't make
token request<br>
<br>
But, as part of the check for removing storage [3], the code
also looks for user interaction - in this example, if the user
has interacted with the RP in the last 7 days (i.e. when the
user clicked sign-in to initiate the request), it won't clear
it. So at a first glance it feels like the effect for RPs is
minimal.<br>
<br>
[1]: <a href="https://github.com/WebKit/webkit/commit/39bc7b05175f71915597e7001594e703247668eb" target="_blank">https://github.com/WebKit/webkit/commit/39bc7b05175f71915597e7001594e703247668eb</a><br>
[2]: <a href="https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-01" target="_blank">https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-01</a><br>
[3]: <a href="https://github.com/WebKit/webkit/commit/39bc7b05175f71915597e7001594e703247668eb#diff-0de9e6ac983b05b8b15a3f1054bc74e5R812" target="_blank">https://github.com/WebKit/webkit/commit/39bc7b05175f71915597e7001594e703247668eb#diff-0de9e6ac983b05b8b15a3f1054bc74e5R812</a><br>
<br>
/r<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, May 29, 2019 at 12:45
PM George Fletcher 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">Hi,<br>
<br>
Just curious if this new merge to clear local storage, could
affect <br>
OpenID Connect providers who might store some information in
local <br>
storage during the authentication event. I think this pretty
much breaks <br>
Dynamic Client Registration from a browser. Given all flows
have <br>
parameters (considered link decoration) it seems like standard
flows <br>
might also be affected.<br>
<br>
<a href="https://bugs.webkit.org/show_bug.cgi?id=195923" rel="noreferrer" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=195923</a><br>
<br>
Other experiences?<br>
<br>
Thanks,<br>
George<br>
<br>
_______________________________________________<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="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>