<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
(Pawel, Roland, excuse me for continuing the SIOP conversation, I am genuinely interested if OpenID Fedenration spec can solve Registration issue in SIOP V2.)</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;"><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">In SIOP model, user can make the final choice of which RP to share the inf with, but they should not be choosing from the list of any RP. They should be
choosing from the list of RPs that SIOP SW decided to trust based on RP metadata. </span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;"><span style="background-color:rgb(255, 255, 255);display:inline !important"><br>
</span></span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;"><span style="background-color:rgb(255, 255, 255);display:inline !important">Trusting VC/VP based on cryptographic verifiability is different from trust between
the entities exchanging those VC/VP.</span></span><br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;"><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;"><span style="margin:0px;font-size:12pt;background-color:rgb(255, 255, 255)">Hence, claim requirements is not the only metadata that OP needs to know about
RP in SIOP model. </span><span style="margin:0px;font-size:12pt;background-color:rgb(255, 255, 255)">SIOP still needs to know<span> </span></span><span style="margin:0px;font-size:12pt;background-color:rgb(255, 255, 255)">id_token_signing_alg_values_supported,<span> </span></span><span style="margin:0px;font-size:12pt;background-color:rgb(255, 255, 255)">subject_identifier_types_supported,
etc. (2.2.3. Relying Party Registration Metadata Values section in SIOP), s</span></span><span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">o I think OIDC Federation ES are good candidates for registration
in SIOP model, but this does mean more operations for SIOP SW.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;"><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">Kindest Regards,</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">Kristina</span></div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>差出人:</b> Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net> が David Chadwick via Openid-specs-ab <openid-specs-ab@lists.openid.net> の代理で送信<br>
<b>送信日時:</b> 2021年6月30日 1:45<br>
<b>宛先:</b> pawel.kowalik@1und1.de <pawel.kowalik@1und1.de><br>
<b>CC:</b> David Chadwick <d.w.chadwick@verifiablecredentials.info>; Artifact Binding/Connect Working Group <openid-specs-ab@lists.openid.net><br>
<b>件名:</b> Re: [Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review</font>
<div> </div>
</div>
<div>
<p><br>
</p>
<div class="x_moz-cite-prefix">On 30/06/2021 09:00, Pawel Kowalik wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi David,
<div><br>
</div>
<div>I think this is where Federation spec sets higher expectations when it comes to assuring RPs identity before releasing the credentials to them.</div>
<div>Leaving it purely up to the user (holder) is the current status quo, but it would be an added value of a federation to offer more security in this respect and protect the holder from malicious RPs.</div>
<div>Even in the real world there are risks involved in showing your ID card to a random person or a company.</div>
<div><br>
</div>
<div>Away from SIOP context, in the enterprise usage I see a lot of expectation for OP to only accept vetted RPs.</div>
</div>
</blockquote>
<p>This is true also in the ISO mDL work. Similarly RPs might wish to only accept credentials from vetted wallets e.g. in banking. So I think different communities are going to place different restrictions on OPs, wallets and RPs that can participate in their
eco-system. But the baseline case should be as unrestricted as possible, within legal limitations such as GDRP, to allow any OP to issue any claim to any user who can access any RP. Otherwise how would the public in general be able to use Google and Amazon
and any services that they point to.<br>
</p>
<p>So I am not against constraints, but they should be optional, and should range from none (in legal limits) to maximal.</p>
<p>Kind regards</p>
<p>David<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br clear="all">
<div>
<div dir="ltr" class="x_gmail_signature">
<div dir="ltr">Kind Regards,
<div>Pawel</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Wed, 30 Jun 2021 at 09:44, David Chadwick <<a href="mailto:d.w.chadwick@verifiablecredentials.info">d.w.chadwick@verifiablecredentials.info</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px
0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div>
<p>Hi Pawel</p>
<p>I have not had time to read the federation spec yet. Sorry about that.</p>
<p>The "Beauty" of the VC trust model is that it breaks the link between the OP and RP. The OP no longer knows who the RP is. Therefore requiring the OP to trust the RP does not enter into the picture. With VCs, the user is put in charge. The user decides
which RPs to trust and which RPs to give their VCs to. In the same way that users today decide who to give their plastic cards to, and the card issuer has no control over this, the VC world mirrors real life. Of course this allows unscrupulous RPs to rob a
user of their privacy. But in the VC system that we have built, we require the RP to publish its claim requirements in a public repository, and our VC wallet will not release any VCs to any RP that has not done this. We are currently discussing supporting
this type of claim reference in the SIOPv2 work. As an alternative to the RP publishing its meta data for federations, in the VC world it would publish its claim requirements in a public repository.<br>
</p>
<p>Kind regards</p>
<p>David<br>
</p>
<div>On 30/06/2021 07:38, Pawel Kowalik wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi David,</div>
<div><br>
</div>
<div>The purpose of RP registration in the federation context is to verify whether the RP is legit part of the federation at all. The assumption is that OP may decide only to accept RPs they can trust based on their respective Entity Statements.</div>
<div>The Automatic Registration allows embedding all of that in one authentication step.</div>
<div><br>
</div>
<div>Entity Statements fulfill to a big extent the same function as VCs/VPs, just being a credential issued by federation trust anchor or intermediate towards OPs or RPs. I think it would be worth a while taking a look whether Federation spec would include
extensibility elements to allow either ECs or VC/VP for this purpose.</div>
<br clear="all">
<div>
<div dir="ltr">
<div dir="ltr">Kind Regards,
<div>Pawel</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Tue, 29 Jun 2021 at 21:43, David Chadwick 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="x_gmail_quote" style="margin:0px 0px
0px 0.8ex; border-left:1px solid
rgb(204,204,204); padding-left:1ex">
<div>
<p>Hi Roland</p>
<p>once SIOP is in use with user wallets, why is client registration needed? I ask this, because when I am using my browser I go to multiple web sites without knowing anything about them first. I might buy something from a RP that I have never visited before.
No prior registration of either myself nor the RP is needed.</p>
<p>So why cannot it work in the same way with SIOP and VCs? The only meta data that is needed prior to any user involvement is that the RP has to know the meta data of the VC Issuers that it trusts. The RP has to know the the VC issuer's X.509 PKC and understand
the schema of the VCs it will issue, and then we are good to go. The user visits the RP's web site, it sends its claim requirements to the user's SIOP wallet, the user chooses VCs that match this and returns a VP to the RP. The RP then validates PoP and that
the VCs were issued by the trusted Issuers. Can you critically appraise this model please.<br>
</p>
<p>Kind regards</p>
<p>David<br>
</p>
<div>On 28/06/2021 08:49, Roland Hedberg via Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite">Hi !
<div><br>
</div>
<div>Thanks Torsten for your comments. I’ll start the answer with the design criteria we had:</div>
<div><br>
</div>
<div>
<div style="margin:0px; font-stretch:normal; line-height:normal">- So far we’ve seen a small number of federation models. One-to-many (Google's 1 OP, many RPs or Amazon's 1 RP and many OPs) and small to fairly large multi lateral federations like EduGAIN (~4400
OPs and 3300 RPs). All of them based on centralised static registration. In order to allow multi lateral federations to grow in size we think that it’s necessary to move to decentralised dynamic registration (imaging if SIOP takes off). </div>
<div style="margin:0px; font-stretch:normal; line-height:normal; min-height:14px">
<br>
</div>
<div style="margin:0px; font-stretch:normal; line-height:normal">- One-to-many OIDC federations normally uses dynamic provider info discovery but not dynamic client registration. </div>
<div style="margin:0px; font-stretch:normal; line-height:normal">Which is not that surprising since classic OIDC client registration in essence is a leap of faith. There is no way you as an OP can </div>
<div style="margin:0px; font-stretch:normal; line-height:normal">verify that the client metadata is correct. We would like to make client registration more robust and allow OPs to verify</div>
<div style="margin:0px; font-stretch:normal; line-height:normal">the correctness of the client metadata.</div>
<div style="margin:0px; font-stretch:normal; line-height:normal; min-height:14px">
<br>
</div>
<div style="margin:0px; font-stretch:normal; line-height:normal">- Federation policies will change over time (like moving from SHA1 to SHA256) we would like to support that and to have built-in</div>
<div style="margin:0px; font-stretch:normal; line-height:normal">support for policies to change dynamically. Also, having decentralised entity registration we need a way to enforce federation policies.</div>
<div style="margin:0px; font-stretch:normal; line-height:normal; min-height:14px">
<br>
</div>
<div style="margin:0px; font-stretch:normal; line-height:normal">- OIDC and OAuth2 both have defined APIs for provider info discovery and client registration the federation specification should </div>
<div style="margin:0px; font-stretch:normal; line-height:normal">work equally well for both.</div>
<div style="margin:0px; font-stretch:normal; line-height:normal; min-height:14px">
<br>
</div>
<div style="margin:0px; font-stretch:normal; line-height:normal">- The messages pushed around in this specification should not depend on TLS for their protection. </div>
<div><br>
</div>
<div>- We should when possible use functionally already present in OIDC libraries (like key handling, signed JWT verifications, JWKS, ..)</div>
<div><br>
</div>
<div>- We should only touch the initial OIDC RP<->OP communication phases (provider info discovery and client registration).</div>
<div>Now, this changed during the work of the specification so there now is one use case where we touch the authorization request.</div>
<div><br>
</div>
<div>- An entity (OP or RP) should be able to belong to more the one federation.</div>
<div><br>
<blockquote type="cite">
<div>On 30 May 2021, at 18:38, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>> wrote:</div>
<div>
<div><br>
I think an overview describing and motivating the design concepts and principles would be helpful to readers.
<br>
<br>
I would also appreciate an explanation why the federation draft design is better suited for the envisioned use cases than X.509 certificates. Deployments need to be convinced to invest into a pretty new solution with a lot of runtime overhead (latency and availability
implications!) while X.509 is used for the same/similar (?) applications in the wild. I’m pretty sure there a good arguments ;-).
<br>
</div>
</div>
</blockquote>
</div>
<br>
<div>
<div dir="auto">
<div style="color:rgb(0,0,0); font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">
— Roland</div>
<div style="color:rgb(0,0,0); font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">
<br>
</div>
<div style="color:rgb(0,0,0); font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">
Were it left to me to decide whether we should have a government without newspapers, or newspapers without a government, I should not hesitate a moment to prefer the latter. -Thomas Jefferson, third US president, architect, and author (1743-1826) </div>
</div>
</div>
<br>
</div>
<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://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C8ae137ec15f24733dd9d08d93ba36f3b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637606395428571889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OytZGKToef5mPnhjaatluUIMbFuPROu7ktRKxoVGW%2Bs%3D&reserved=0" originalsrc="http://lists.openid.net/mailman/listinfo/openid-specs-ab" shash="XYxSTPzCftleF/NzMrVUc6MvAV69q5uMQrzPz4qd6+2011pdhT1d7WpdRf7nmVlXgwtdlYQSzkSEkQexghVge7ERvEBdOndd1SuWMTbf7iZXJNkTTG4pyyTekzQtzf5SC5aQxgpHFtz0/9yrIIL0CZVwxyaApy341TAT9ANaDmw=" target="_blank">http://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://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C8ae137ec15f24733dd9d08d93ba36f3b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637606395428581844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EkGFvDGvWU7xq5L5Ic81QV0sSw0DXga%2FroQPWvfkKco%3D&reserved=0" originalsrc="http://lists.openid.net/mailman/listinfo/openid-specs-ab" shash="Q+aWJ/wPQgpR1r5pmV6nrg8NXIPks1CPS5emdkrv0JdJKLB0quK4S2iPuHNXhMxq9waK8cc9e3jcv9k04fhhGh3lPL5XsrU2L8AOWhXgFLpvdZ4JruMtrQBH3mPraP3I1X6GfB+PzIpX2SN+dC2SwBYAj5bwC4fgO95vTYeZaks=" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</body>
</html>