<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" 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 mail.google.com
as the URL in the browser:)<br>
<br>
Thanks,<br>
George<br>
<br>
<div class="moz-cite-prefix">On 6/4/19 11:06 AM, Reman Child wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHa0KHR6AikpcxhBi_R6xW7d3Ja8K-qWPi0RzMiwJNpkWskiXQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">https://github.com/WebKit/webkit/commit/39bc7b05175f71915597e7001594e703247668eb</a><br>
[2]: <a
href="https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-01"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br>
<a
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>