<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi David, <br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 26. Feb 2022, at 16:35, David Chadwick <<a href="mailto:d.w.chadwick@verifiablecredentials.info" class="">d.w.chadwick@verifiablecredentials.info</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="">
<div class="moz-cite-prefix">Hi Torsten</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">On 26/02/2022 13:33, Torsten
Lodderstedt wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:A0BA4530-8B36-4F62-B7AF-EABA12E7BF13@lodderstedt.net" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
Hi David,
<div class=""><br class="">
</div>
<div class="">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 class="">
</div>
</blockquote><p class="">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 class="">
</p>
<blockquote type="cite" cite="mid:A0BA4530-8B36-4F62-B7AF-EABA12E7BF13@lodderstedt.net" class="">
<div class=""><br class="">
</div>
<div class="">How would you compare it to OpenID Connect
Federations?</div>
</blockquote><p class="">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 class=""><br class="">
</p>
<blockquote type="cite" cite="mid:A0BA4530-8B36-4F62-B7AF-EABA12E7BF13@lodderstedt.net" class="">
<div class="">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 class="">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 class=""><a class="moz-txt-link-freetext" href="https://gitlab.grnet.gr/essif-lab/infrastructure/fraunhofer/train-source-code/-/tree/master/TRAIN-ATV-API">https://gitlab.grnet.gr/essif-lab/infrastructure/fraunhofer/train-source-code/-/tree/master/TRAIN-ATV-API</a></p></div></div></blockquote>Is it limited to VCs? I’m asking since I want to understand whether one could also manage trust in a federation of OIDC OPs with the TRAIN API. </div><div><br class=""></div><div>best regards,</div><div>Torsten. <br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">
</p><p class="">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 class="">I hope this helps</p><p class="">Kind regards</p><p class="">David<br class="">
</p>
<blockquote type="cite" cite="mid:A0BA4530-8B36-4F62-B7AF-EABA12E7BF13@lodderstedt.net" class="">
<div class=""><br class="">
</div>
<div class="">best regards,</div>
<div class="">Torsten. <br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 21. Feb 2022, at 18:54, David Chadwick via
Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="moz-txt-link-freetext" moz-do-not-send="true">openid-specs-ab@lists.openid.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8" class="">
<div class=""><p class="">Hi Everyone</p><p class="">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 class="moz-txt-link-freetext" href="https://oid2022.compute.dtu.dk/" moz-do-not-send="true">https://oid2022.compute.dtu.dk/</a>)
and we will know by the end of March whether it has
been accepted or not.</p><p class="">Kind regards</p><p class="">David<br class="">
</p>
</div>
<span id="cid:4D63B6E9-9BB0-4231-B98A-D642CBDC90DE" class=""><A
novel approach to establish trust in verifiable
credential issuers using TRAIN.pdf></span>_______________________________________________<br class="">
Openid-specs-ab mailing list<br class="">
<a href="mailto:Openid-specs-ab@lists.openid.net" class="moz-txt-link-freetext" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br class="">
<a class="moz-txt-link-freetext" href="https://lists.openid.net/mailman/listinfo/openid-specs-ab">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote><p class=""><br class="">
</p>
</div>
</div></blockquote></div><br class=""></body></html>