<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Giuseppe</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 26/02/2022 17:04, Giuseppe De Marco
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAP_qYykMM7-B39iW5FR3ay-Z2cAi9FhCSn_1hvRqnPPfLK7wjg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi David,<br>
Excuse me if I fit in, it’s hard to keep me, especially thanks
for sharing the paper, really rich in ideas.<br>
</div>
</blockquote>
Great for you to join in. Thanks.<br>
<blockquote type="cite"
cite="mid:CAP_qYykMM7-B39iW5FR3ay-Z2cAi9FhCSn_1hvRqnPPfLK7wjg@mail.gmail.com">
<div dir="ltr"><br>
When you say about OIDC Fed 1.0 and the x509 PKI infrastructure
you're right, the path to the trust is an important
implementation to cover.<br>
Then you say "That seems like a lot of heavy lifting compared to
simply calling the TRAIN ATV API which does it all for you."<br>
<br>
It is precisely on this need that the endpoint Resolve Statement
in OIDC Federation moves, to offer a simplification and
hopefully in the future also an interface of interoperability
towards other technologies.<br>
This endpoint was born as an optional tool but I think it was
important to have it included in the specification, to offer
this simplification that you exalt in TRAIN.<br>
</div>
</blockquote>
<p>I agree. I remember when this endpoint was discussed in the group
meeting, and I also think that this should be included so as to
make things as simple as possible for RPs. Not only to make
coding/configuring them easier, but also to make it easier to
understand the concepts so that mistakes are not made in
implementations.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAP_qYykMM7-B39iW5FR3ay-Z2cAi9FhCSn_1hvRqnPPfLK7wjg@mail.gmail.com">
<div dir="ltr"><br>
There is also an aspect that I consider important in the design
of infrastructure, the fact that these may be distributed
vertically. A Ledger is basically flat, the model of OIDC
Federation is rather tree-shaped, in this we can identify
sub-federations and each verifier decides which trust anchor to
consider on the basis of its own purposes and the federation of
reference within which it wants to operate.<br>
</div>
</blockquote>
<p>This is one of the differences between federation and TRAIN. With
TRAIN the verifier delegates the trust-in-issuer decision to its
TRAIN operator (of course it can have its own untrusted list that
overrides this e.g. any US University except tinpot.edu) rather
than being able to chose any node in the federation
tree/graph/mesh as its trust anchor. The TRAIN operator could
include other TRAIN operators (via PTR RRs) thus creating a trust
graph, but the verifier will trust its TRAIN operator to do this
and may be unaware of it. One example we have for this, is that
each EU country could have its own ETSI trust list, and one
country's TRAIN operator could trust some of the other countries
that it believes operate equivalent certification procedures.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAP_qYykMM7-B39iW5FR3ay-Z2cAi9FhCSn_1hvRqnPPfLK7wjg@mail.gmail.com">
<div dir="ltr"><br>
Think of the European Union and national self-government. With
OIDC Federation we can create national federations in turn
intermediaries of one or more higher level federations, such as
a European or other.<br>
</div>
</blockquote>
<p>You probably know that the EC already operates an ETSI list of
lists, which points to all the country based trust lists. So this
is already operational for X.509 trust lists.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAP_qYykMM7-B39iW5FR3ay-Z2cAi9FhCSn_1hvRqnPPfLK7wjg@mail.gmail.com">
<div dir="ltr">I also think about storage. OIDC Federation
proposes an API and not a storage. A storage that you know can
be distributed (even on Ledger) making multiple trust anchors a
distributed API.<br>
</div>
</blockquote>
This is another difference. TRAIN uses the DNS as its pointer
storage mechanism (as this is a fundamental trusted root for the
whole Internet) with HTTPS URLs holding the actual trust lists. The
original implementation (in the EC Lightest Project) used DNSSec
only to make the DNS lookups, but this was relaxed in TRAIN to use
plain DNS due to the fact that DNSSec is not rolled out everywhere.
Distributed APIs are fully supported in TRAIN, as multiple operators
can run the TRAIN AVS API and each verifier can configure in one or
more of these endpoints so as to build in resilience.<br>
<blockquote type="cite"
cite="mid:CAP_qYykMM7-B39iW5FR3ay-Z2cAi9FhCSn_1hvRqnPPfLK7wjg@mail.gmail.com">
<div dir="ltr"><br>
I’m missing the narration of SIOP and VP and will resume it as
soon as possible, but I don’t remember that a VC or a VP can
have multiple DID associated to it.<br>
</div>
</blockquote>
<p>Yes a VC can have multiple URIs (I prefer to use URIs rather than
DIDs as the latter are a subset of the former, and our VC eco
system uses HTTPS URIs and not DIDs). Consider a marriage
certificate that belongs to two subjects. This will need to have
two URIs. A VP would typically only have one URI to prove
possession of the embedded VC. But if the embedded VCs have
different URIs then the VP might need to contain multiple ones as
well. LD-Proofs will allow this, but currently JWT VCs/VPs dont
because we specify the compact encoding. But V2 of the VC data
model could allow multiply signed JWTs (this work has not started
yet but it is in the scope).<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAP_qYykMM7-B39iW5FR3ay-Z2cAi9FhCSn_1hvRqnPPfLK7wjg@mail.gmail.com">
<div dir="ltr">While on OIDC Federation a leaf can have many
authority hints, therefore a leaf can propose multiple paths for
the resolution of trust. It may also apply to several
federations at the same time on a horizontal level.<br>
</div>
</blockquote>
This is also allowed in TRAIN. A VC issuer simply includes multiple
Trust Scheme DNS names in its ToU property indicating that it is a
member of multiple trust schemes.<br>
<blockquote type="cite"
cite="mid:CAP_qYykMM7-B39iW5FR3ay-Z2cAi9FhCSn_1hvRqnPPfLK7wjg@mail.gmail.com">
<div dir="ltr"><br>
A useful reflection on my part takes place in the url of the
subjects within oidc federation. Well, what changes would be
needed to the specification to support SSI URIs and thus obtain
DID resolution mechanisms also in OIDC Federation?<br>
</div>
</blockquote>
<p>Since I dont use DIDs, I have not thought about this. Sorry!!</p>
<p>Kind regards</p>
<p>David<br>
</p>
<blockquote type="cite"
cite="mid:CAP_qYykMM7-B39iW5FR3ay-Z2cAi9FhCSn_1hvRqnPPfLK7wjg@mail.gmail.com">
<div dir="ltr"><br>
It's time to Stop me... :)<br>
best<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Il giorno sab 26 feb 2022 alle
ore 16:35 David Chadwick via Openid-specs-ab <<a
href="mailto:openid-specs-ab@lists.openid.net"
moz-do-not-send="true" class="moz-txt-link-freetext">openid-specs-ab@lists.openid.net</a>>
ha scritto:<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>
<div>Hi Torsten</div>
<div><br>
</div>
<div>On 26/02/2022 13:33, Torsten Lodderstedt wrote:<br>
</div>
<blockquote type="cite"> Hi David,
<div><br>
</div>
<div>thanks for sharing this paper. I like the pragmatism
of the work and the way it leverages DNS and ETSi Trust
Lists (even though this means to use XML ….). <br>
</div>
</blockquote>
<p>The other advantage is that the TRAIN API is open source
and is very easy to integrate into any VC-eco system. It
is also easy for federation operators to manage their DNS
entries. I am assuming that ETSI trust lists also have a
set of tools to make them easy to manage, but in the eSSIF
project this work was performed by Fraunhofer rather than
myself so I have no practical experience of managing them
(though I am familiar with their contents).<br>
</p>
<blockquote type="cite">
<div><br>
</div>
<div>How would you compare it to OpenID Connect
Federations?</div>
</blockquote>
<p>I have no experience of working with these, but they
appear to resemble X.509 PKI trust chains, and require the
callers (RPs) to walk the trust chains to their trust
anchors and do the processing of federation policies
themselves. That seems like a lot of heavy lifting
compared to simply calling the TRAIN ATV API which does it
all for you.</p>
<p><br>
</p>
<blockquote type="cite">
<div>Could the average developer handle it without the ATV
API? I’m asking since I’m not familiar with the details
on DNS programming.</div>
</blockquote>
<p>Which developers are we referring to? If we are talking
about RP software developers, then calling the open source
TRAIN ATV API is much simpler than interacting with
published OIDC Federation metadata. Why would such a
developer who wishes to use TRAIN not use the ATV API,
given its an Apache license and the code is freely
available here:</p>
<p><a
href="https://gitlab.grnet.gr/essif-lab/infrastructure/fraunhofer/train-source-code/-/tree/master/TRAIN-ATV-API"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://gitlab.grnet.gr/essif-lab/infrastructure/fraunhofer/train-source-code/-/tree/master/TRAIN-ATV-API</a><br>
</p>
<p>OTOH, If we are talking about federation operators, then
we need to compare and contrast managing an ETSI trust
list and your own DNS entries, with that of establishing
the federation meta data and setting up bi-lateral trust
arrangements with federation members. This would be an
interesting piece of research to do.</p>
<p>I hope this helps</p>
<p>Kind regards</p>
<p>David<br>
</p>
<blockquote type="cite">
<div><br>
</div>
<div>best regards,</div>
<div>Torsten. <br>
<div><br>
<blockquote type="cite">
<div>On 21. Feb 2022, at 18:54, David Chadwick via
Openid-specs-ab <<a
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-ab@lists.openid.net</a>>
wrote:</div>
<br>
<div>
<div>
<p>Hi Everyone</p>
<p>here is the paper that describes the
rationale for, and the technology used by, the
TRAIN trust infrastructure, as described in
PR#107 for the implementation section of
OIDC4VPs. This paper has been submitted to the
Open Identity Summit 2022 (<a
href="https://oid2022.compute.dtu.dk/"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://oid2022.compute.dtu.dk/</a>)
and we will know by the end of March whether
it has been accepted or not.</p>
<p>Kind regards</p>
<p>David<br>
</p>
</div>
<span
id="gmail-m_-4853835558823342062cid:4D63B6E9-9BB0-4231-B98A-D642CBDC90DE"><A
novel approach to establish trust in verifiable
credential issuers using TRAIN.pdf></span>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-ab@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<p><br>
</p>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-ab@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>