<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><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Kind Regards,<div>Pawel</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="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="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="gmail_quote">
<div dir="ltr" class="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="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="http://lists.openid.net/mailman/listinfo/openid-specs-ab" 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="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>