[Openid-specs-ab] TRAIN paper

[Giuseppe De Marco]

Hi David,
Excuse me if I fit in, it’s hard to keep me, especially thanks for sharing
the paper, really rich in ideas.

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.
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."

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.
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.

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.

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.
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.

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.
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.

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?

It's time to Stop me... :)
best

Il giorno sab 26 feb 2022 alle ore 16:35 David Chadwick via Openid-specs-ab
<openid-specs-ab at lists.openid.net> ha scritto:

> 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
>
> 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> 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/) 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
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> 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/7c5016a8/attachment.html>