<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 30/06/2021 09:00, Pawel Kowalik
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANYDG0t_a4eoEfwT0ydPvytN4ppzJRt0ViVfFw+nLEe8LFqM-g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
cite="mid:CANYDG0t_a4eoEfwT0ydPvytN4ppzJRt0ViVfFw+nLEe8LFqM-g@mail.gmail.com">
<div dir="ltr">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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" 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="http://lists.openid.net/mailman/listinfo/openid-specs-ab" 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="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
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>
</body>
</html>