<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello!</p>
<p>I want to say it just in case that I still don't have a solution
to the problem I described in the above messages, so any
suggestions are welcome.</p>
<p>senya<br>
</p>
<div class="moz-cite-prefix">25.12.2018 11:01, senya пишет:<br>
</div>
<blockquote type="cite"
cite="mid:7658a88a-e95f-c3b3-6d87-3f6ac3b6b931@riseup.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Oh, I see. So It's possible that AccountChooser does the server
resolution even when this server was never known before by the
authorization client? Because you wrote</p>
<br>
> AccountChooser presents the list of IdPs that the user has
used against the domain and let her chose it<br>
<br>
<p>And I understood that like I have to discover the IdP in
advance.</p>
<p>I think you understood my use case correctly.<br>
</p>
<p>Well, the problem with the solution you propose (with
AccountChooser) is that I have to implement some
discovery-specific support on the diaspora site. The way the
custom protocol handlers work, the authorization client can
redirect to the custom protocol address from the login page
(e.g. the AccountChooser). And in order to use this to resolve
the remote host (diaspora) the IdP has to redirect it back to
the original service. So when I redirect to
"web+diaspora://authenticate" from the AccountChooser in order
to resolve the target host I'll have to redirect back from
diaspora to the URL of the authorization client with the host
name in the request parameters. And only after that I can do the
OIDC authorization flow. <br>
</p>
<p>Besides the fact that this way I'll have two redirect-callback
rounds between the same two services, it also has some privacy
issues, because implementing an endpoint which unconditionally
redirects back and telling your diaspora server host name can be
used to identify the host name even when user doesn't want it.
This issue can be solved by asking the user at the diaspora site
something like "Do you want to tell example.com your host name?"
but this would also mean that the user will be asked twice: once
for the host name and second time for the OIDC authorization
permission which is a terrible UX.</p>
<p>That's why I looked at the "implicit registration flow" which
actually combines this two things into one redirect-callback
round: it redirects to the custom protocol URL and then goes
back to the authorization client with the authorization
response. If the user refused the authorization we can redirect
without telling the hostname which solve the privacy concern.</p>
<p>Thanks for the detailed response, though!<br>
</p>
<div class="moz-cite-prefix">25.12.2018 10:13, n-sakimura пишет:<br>
</div>
<blockquote type="cite"
cite="mid:OSBPR01MB2869529313113860C823EA93F9B40@OSBPR01MB2869.jpnprd01.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered

medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"ＭＳ ゴシック";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@ＭＳ ゴシック";
panose-1:2 11 6 9 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
span.19
{mso-style-type:personal;
font-family:"Arial",sans-serif;
color:windowtext;}
span.20
{mso-style-type:personal-reply;
font-family:"Arial",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:99.25pt 3.0cm 3.0cm 3.0cm;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:714425180;
mso-list-type:hybrid;
mso-list-template-ids:-1188901486 1956534454 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;
mso-fareast-font-family:"ＭＳ ゴシック";
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1248731252;
mso-list-type:hybrid;
mso-list-template-ids:2070153668 1956534454 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;
mso-fareast-font-family:"ＭＳ ゴシック";
mso-bidi-font-family:"Times New Roman";}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Hmmm.
Then I am not understanding your use-case properly. <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">What
I understood was as follows: <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph"
style="color:windowtext;margin-left:0cm;mso-list:l0
level1
 lfo1"> <span
style="font-family:"Arial",sans-serif">There
is a diaspora user who wants to login to a service. <o:p></o:p></span></li>
<li class="MsoListParagraph"
style="color:windowtext;margin-left:0cm;mso-list:l0
level1
 lfo1"> <span
style="font-family:"Arial",sans-serif">However,
diaspora being distributed, there has to be a way to
find out which server the user is using. <o:p></o:p></span></li>
</ul>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">So,
that is the objective, right? <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Your
proposed solution to it is to<o:p></o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph"
style="color:windowtext;margin-left:0cm;mso-list:l1
level1
 lfo2"> <span
style="font-family:"Arial",sans-serif">Utilize
a custom protocol handler so that the user can be
redirected to the service. <o:p></o:p></span></li>
</ul>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Is
this correct? <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">If
so, my next question is why does it not suffice for the
site to find out the diaspora server URL using
AccountChoser? Once the client gets the address of the
diaspora server, it can register itself to it and start
the standard OpenID Connect flow. What is the reason that
this does not work? <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Cheers,
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Nat
Sakimura<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1

1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span
style="color:windowtext"> senya <a
class="moz-txt-link-rfc2396E"
href="mailto:senya@riseup.net"
moz-do-not-send="true"><senya@riseup.net></a>
<br>
<b>Sent:</b> Tuesday, December 25, 2018 4:12 PM<br>
<b>To:</b> n-sakimura <a
class="moz-txt-link-rfc2396E"
href="mailto:n-sakimura@nri.co.jp"
moz-do-not-send="true"><n-sakimura@nri.co.jp></a>;
Nat Sakimura <a class="moz-txt-link-rfc2396E"
href="mailto:sakimura@gmail.com"
moz-do-not-send="true"><sakimura@gmail.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated"
href="mailto:openid-specs@lists.openid.net"
moz-do-not-send="true">openid-specs@lists.openid.net</a><br>
<b>Subject:</b> Re: OpenID Connect with custom
protocol handlers in browser<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Yeah, but that's not what I want.<o:p></o:p></p>
<div>
<p class="MsoNormal">25.12.2018 9:06, n-sakimura пишет:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">AccountChooser
presents the list of IdPs that the user has used against
the domain and let her chose it. </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Then,
the client receives the IdP that the user has selected
so that the normal federated login can be done. </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Cheers,
</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Nat</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1

1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span
style="color:windowtext"> specs <a
href="mailto:openid-specs-bounces@lists.openid.net"
moz-do-not-send="true"><openid-specs-bounces@lists.openid.net></a>
<b>On Behalf Of </b>senya<br>
<b>Sent:</b> Tuesday, December 25, 2018 3:44 PM<br>
<b>To:</b> Nat Sakimura <a
href="mailto:sakimura@gmail.com"
moz-do-not-send="true"><sakimura@gmail.com></a><br>
<b>Cc:</b> <a
href="mailto:openid-specs@lists.openid.net"
moz-do-not-send="true">openid-specs@lists.openid.net</a><br>
<b>Subject:</b> Re: OpenID Connect with custom
protocol handlers in browser</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p>Hello, Nat.<o:p></o:p></p>
<p>Thanks for the link, but however I can't see how it
overlaps with my use case. AccountChooser / OpenYOLO seem
to describe something like credential managers, while I
want to implement sign in with an authentication provider.
It's like "Sign in with Facebook", but with diaspora*
social network instead. The only difference is that
diaspora* social network is federated, therefore there is
no single entry point like "facebook.com" to send
authentication request. This is the problem that I'm
trying to solve. I can't see how the specifications you've
referenced can help, but maybe I'm just missing something?<o:p></o:p></p>
<div>
<p class="MsoNormal">24.12.2018 4:49, Nat Sakimura пишет:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white">TL;DR
but your usecase seems to somewhat overlap with
AccountChooser / OpenYOLO. Have you checked them? </span>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white"><br>
<br>
<br>
</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white"><a
href="https://openid.net/wg/ac/"
moz-do-not-send="true">https://openid.net/wg/ac/</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white">Cheers, </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white">Nat </span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">2018<span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA">年</span>12<span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA">月</span>24<span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA">日</span>(<span
style="font-family:"ＭＳ
 ゴシック",serif"
lang="JA">月</span>) 3:15<span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA">、</span>senya <span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA"> さん（</span><a
href="mailto:senya@riseup.net"
moz-do-not-send="true">senya@riseup.net</a><span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA">）のメッセージ</span>:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid
#CCCCCC
 1.0pt;padding:0cm 0cm
0cm
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal">Hello!<br>
<br>
I'm trying to figure out if it is possible to
implement OpenID Connect<br>
client authorization using a custom protocol handler
registered by a<br>
user in browser.<br>
<br>
I'm a software developer and I'm researching the
possibility of<br>
implementing "sign in with diaspora*" feature for
3rd party websites to<br>
authenticate with diaspora* federated social
network accounts.<br>
Diaspora* supports OIDC with the Dynamic Client
Registration extension.<br>
<br>
<br>
Imagine there is a federated web service, which has
different web entry<br>
points. Imagine that this federated service supports
custom protocol<br>
handler. For example diaspora* supports registering
`web+diaspora://`<br>
protocol handler using `registerProtocolHandler`<br>
[<a
href="https://developer.mozilla.org/ru/docs/Web/API/Navigator/registerProtocolHandler"
target="_blank" moz-do-not-send="true">https://developer.mozilla.org/ru/docs/Web/API/Navigator/registerProtocolHandler</a>]<br>
browser API call.<br>
<br>
Each user has a specific entry point to this
federated service, i.e. a<br>
website where the user has login credentials. Users
can register a<br>
custom protocol handler for their entry points and
when the user follows<br>
the custom protocol link, the link will be opened on
the correct web<br>
site for this user. The login credentials represent
the user's identity<br>
in the federated service.<br>
<br>
My question is: whether it is possible to use OpenID
Connect to<br>
implement "sign in with" feature for 3rd party
clients to allow users to<br>
sign in using the user's federated identity with
using the custom<br>
protocol handlers to discover the entry point?<br>
<br>
I did some research, but I didn't find an answer.<br>
<br>
What I expect is that when a user requests "sign in
with diaspora*"<br>
button at the 3rd party web site, the browser
redirects this request to<br>
the custom protocol URI, which is resolved by the
web browser and opened<br>
on the proper federated service node, where the
authorization will<br>
happen and the redirected back to the 3rd party site
using the<br>
`redirect_url` according to OpenID Connect.<br>
<br>
So the main difference from most of the OpenID
Connect authorization<br>
providers is that the real address of the
authorization providers is not<br>
known in advance. However we suppose that the user
has registered a<br>
custom protocol handler in their browser. If we use
the custom protocol<br>
link at the authorization phase, then the user's web
browser will<br>
redirect the request to the correct web node. The
first problem here is<br>
that you can't use a preshared secret to identify
the 3rd party site<br>
because the nodes are not predefined.<br>
<br>
I discovered the "OpenID Connect Federation"<br>
[<a
href="https://openid.net/specs/openid-connect-federation-1_0.html"
target="_blank" moz-do-not-send="true">https://openid.net/specs/openid-connect-federation-1_0.html</a>]<br>
specification draft which covers so called "Implicit
registration". This<br>
allows to register the OIDC client at the time when
the authorization<br>
request is made. This partially solved this problem.
So when OIDC client<br>
uses a custom protocol URI as an authorization
endpoint, the<br>
authorization provider will receive this request and
then discover the<br>
OIDC client using the dynamic registration protocol.<br>
<br>
So for example when you push the "sign in with
diaspora*" button you're<br>
being redirected to
`web+diaspora://authenticate?authorization_params`<br>
which is resolved for you into the<br>
`<a
href="https://your-federation-node.tld/link_handler?url=authenticate?authorization_params"
target="_blank" moz-do-not-send="true">https://your-federation-node.tld/link_handler?url=authenticate?authorization_params`</a><br>
URL which is then requested and upon the request the
original OIDC<br>
client is being discovered.<br>
<br>
By using this technique I managed to pass the
authorization phase.<br>
However there another problem arose. I don't know
how is it possible to<br>
pass the real host name of the OIDC auth provider
back to the OIDC client.<br>
<br>
In a simple setup when authorization is successful
authorization result<br>
is a code. However in my example, if we respond to
the OIDC client with<br>
a code, the OIDC client will not know where this
code came from. This is<br>
because the authorization request was sent to the
custom protocol URI,<br>
not the real URI. The only source of the information
here is HTTP<br>
referrer of the authorization callback which cannot
be relied upon.<br>
<br>
I found this document<br>
[<a
href="https://openid.net/specs/openid-financial-api-jarm-ID1.html#the-jwt-response-document"
target="_blank" moz-do-not-send="true">https://openid.net/specs/openid-financial-api-jarm-ID1.html#the-jwt-response-document</a>]<br>
which describes replying to authorization request
using a JWT token<br>
which includes the `iss` (issuer) field, which can
be used to identify<br>
the actual node of the federated service. However
the same document states:<br>
<br>
> Assumption: the client remembers the
authorization server to which it<br>
sent the authorization request and binds this
information to the user<br>
agent.<br>
<br>
> The client obtains the iss element from the JWT
and checks whether its<br>
value is well known and identifies the expected
issuer of the<br>
authorization process in examination. If the check
fails, the client<br>
MUST abort processing and refuse the response.<br>
<br>
However when combined with the implicit registration
the authorization<br>
server is not known at the point when we send the
authorization request.<br>
We can't remember the server at the request time
because we don't know<br>
the server and therefore we can't validate the
response. This means that<br>
it is not possible to use this JWT token
authorization response along<br>
with the implicit client registration which makes it
impossible to<br>
implement it without breaking the protocol. Did I
get that right?<br>
<br>
Is there a way to implement the described feature
and remain in comply<br>
with the OIDC protocols?<br>
<br>
Can JWT authorization response can be used in a
combination with the<br>
implicit client registration from OIDC Federation?<br>
<br>
With best regards,<br>
<br>
Senya.<br>
<br>
<br>
<br>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net"
target="_blank" moz-do-not-send="true">specs@lists.openid.net</a><br>
<a
href="http://lists.openid.net/mailman/listinfo/openid-specs"
target="_blank" moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs</a><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
specs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
</body>
</html>