<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><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><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><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>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><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>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><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><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">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">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">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">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">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">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">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>