[Openid-specs-ab] TRAIN paper

[Torsten Lodderstedt]

Hi David, 

> On 26. Feb 2022, at 16:35, David Chadwick <d.w.chadwick at verifiablecredentials.info> wrote:
> 
> Hi Torsten
> 
> On 26/02/2022 13:33, Torsten Lodderstedt wrote:
>> Hi David, 
>> 
>> 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 ….). 
> 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).
> 
>> 
>> How would you compare it to OpenID Connect Federations?
> 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.
> 
> 
> 
>> Could the average developer handle it without the ATV API? I’m asking since I’m not familiar with the details on DNS programming.
> 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:
> 
> 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>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. 

best regards,
Torsten. 
> 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.
> 
> I hope this helps
> 
> Kind regards
> 
> David
> 
>> 
>> best regards,
>> Torsten.  
>> 
>>> On 21. Feb 2022, at 18:54, David Chadwick via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> wrote:
>>> 
>>> Hi Everyone
>>> 
>>> 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 (https://oid2022.compute.dtu.dk/ <https://oid2022.compute.dtu.dk/>) and we will know by the end of March whether it has been accepted or not.
>>> 
>>> Kind regards
>>> 
>>> David
>>> 
>>> <A novel approach to establish trust in verifiable credential issuers using TRAIN.pdf>_______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab <https://lists.openid.net/mailman/listinfo/openid-specs-ab>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220226/8435cdb8/attachment.html>