<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<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]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<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 <senya@riseup.net>
<br>
<b>Sent:</b> Tuesday, December 25, 2018 4:12 PM<br>
<b>To:</b> n-sakimura <n-sakimura@nri.co.jp>; Nat Sakimura <sakimura@gmail.com><br>
<b>Cc:</b> openid-specs@lists.openid.net<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"><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"><sakimura@gmail.com></a><br>
<b>Cc:</b> <a href="mailto:openid-specs@lists.openid.net">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/">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 lang="JA" style="font-family:"ＭＳ ゴシック",serif">年</span>12<span lang="JA" style="font-family:"ＭＳ ゴシック",serif">月</span>24<span lang="JA" style="font-family:"ＭＳ ゴシック",serif">日</span>(<span lang="JA" style="font-family:"ＭＳ ゴシック",serif">月</span>)
3:15<span lang="JA" style="font-family:"ＭＳ ゴシック",serif">、</span>senya <span lang="JA" style="font-family:"ＭＳ ゴシック",serif">
さん（</span><a href="mailto:senya@riseup.net">senya@riseup.net</a><span lang="JA" style="font-family:"ＭＳ ゴシック",serif">）のメッセージ</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">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">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">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">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">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</blockquote>
</div>
</body>
</html>