<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Kristina</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 30/06/2021 19:33, Kristina Yasuda
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:MW4PR21MB200256CD1BA91683F0C41088E5019@MW4PR21MB2002.namprd21.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
<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. <br>
</span></div>
</blockquote>
<p>Is trust the right word to use here?</p>
<p>Is is not rather the RP metadata that it can interwork with?</p>
<p><br>
</p>
<p>In general it cannot be trust, otherwise the user is no longer in
control of their VCs, and the SW provider is (as in the case for
web browsers)</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:MW4PR21MB200256CD1BA91683F0C41088E5019@MW4PR21MB2002.namprd21.prod.outlook.com">
<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>
</blockquote>
<p>Correct. This is why I would not call the first trust, but rather
compatibility or another word that implies they can interwork
successfully.</p>
<p> <br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:MW4PR21MB200256CD1BA91683F0C41088E5019@MW4PR21MB2002.namprd21.prod.outlook.com">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
</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.</span></span></div>
</blockquote>
<p>Yes, these are interworking parameters not trust parameters.</p>
<p><br>
</p>
<p>Kind regards</p>
<p>David</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:MW4PR21MB200256CD1BA91683F0C41088E5019@MW4PR21MB2002.namprd21.prod.outlook.com">
<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)"> (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>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>差出人:</b>
Openid-specs-ab
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ab-bounces@lists.openid.net"><openid-specs-ab-bounces@lists.openid.net></a> が David
Chadwick via Openid-specs-ab
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ab@lists.openid.net"><openid-specs-ab@lists.openid.net></a> の代理で送信<br>
<b>送信日時:</b> 2021年6月30日 1:45<br>
<b>宛先:</b> <a class="moz-txt-link-abbreviated" href="mailto:pawel.kowalik@1und1.de">pawel.kowalik@1und1.de</a>
<a class="moz-txt-link-rfc2396E" href="mailto:pawel.kowalik@1und1.de"><pawel.kowalik@1und1.de></a><br>
<b>CC:</b> David Chadwick
<a class="moz-txt-link-rfc2396E" href="mailto:d.w.chadwick@verifiablecredentials.info"><d.w.chadwick@verifiablecredentials.info></a>; Artifact
Binding/Connect Working Group
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ab@lists.openid.net"><openid-specs-ab@lists.openid.net></a><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"
moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>