[Openid-specs-ab] SIOP, Trust Frameworks, and SSI/Open Source

Tom Jones thomasclinganjones at gmail.com
Mon May 17 22:06:09 UTC 2021

Amen bro, howsoever, I am ready to pick one method and try to get it
adopted by one trust authority.

thx ..Tom (mobile)

On Mon, May 17, 2021, 1:48 PM David Waite <david at alkaline-solutions.com>

> On May 17, 2021, at 10:55 AM, David Chadwick via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> On 17/05/2021 17:49, Tom Jones wrote:
> Yes, that is my level zero. So attribute based access control is what you
> dislike.
> No, how did you infer that? I quite like it.
> This is the very place where a did pseudonym can work if we can overcome
> the addressing issues. Which are blocking right now.
> Its did pseudonyms that are more problematic for me, not least because
> large ACLs will be needed, also there are over 90 registered methods which
> are growing all the time. And blockchains are typically needed if you want
> to resolve dids to did documents.
> Personally, I find it very challenging to find a definitive use case for
> DIDs.
> The a wide range of method specifications and optional features, along
> with the lack of a baseline set of capabilities from a DID document, make
> generalized DID acceptance very difficult. Between the correlation concerns
> and the need to negotiate acceptable DID methods, I suspect that public
> DIDs will be finer-grained than personas to account for the differing
> requirements for interoperability with other parties. In other words, I
> have doubts that a single public-facing identifier will have enough
> baseline functionality and acceptance to really work across use
> cases/federations without being specifically chosen with that
> interoperability in mind.
> On the other hand, you can have pairwise DIDs within pairwise
> relationships - but that might not have as much value as public scenarios.
> In pairwise scenarios, the metadata of what a subject identifier means does
> not need to be globally resolved/persisted - it is part of the context of
> that pairwise relationship. The did:peer method exists specifically around
> the idea that it may be a pointer to a non-externally-resolvable
> representation of current metadata.
> The gaps where they appear to be most useful is in non-hosted issuers, web
> of trust scenarios and for supporting n-wise relationships. However, the
> DID method resolution process may be substantial and a universal DID
> resolver must be engineered as a trusted system, perhaps pushing these
> scenarios down even harder to supporting a limited set of DID methods.
> -DW
> Kind regards
> David
> thx ..Tom (mobile)
> On Mon, May 17, 2021, 9:36 AM David Chadwick <
> d.w.chadwick at verifiablecredentials.info> wrote:
>> On 17/05/2021 17:18, Tom Jones wrote:
>> The Zero trust part says that i do not trust any message that i receive
>> until i have had the opportunity to vet it to the level of assurance that
>> is appropriate for the transaction. That vetting may be included in the
>> session ID or some other evaluation, but some process does occur on every
>> message received.
>> this I do agree with. But in my mental model, a RP is contacted by a
>> stranger who wants to access one of its protected resources. The RP returns
>> its policy to the stranger (which sets out which VCs containing which
>> identity attributes it wants from which issuers) and the stranger returns a
>> VP. The RP verifies that the VP belongs to the stranger, and that issuers
>> it trusts have certified the various identity attributes of the stranger.
>> So now the RP can apply an ABAC policy/PDP to grant access to the stranger
>> using the validated attributes of the stranger.
>> The RP can repeat this for each resource it owns, i.e. zero trust for
>> each different resource access request,  by assigning different policies to
>> each resource. In this way least privileges can be implemented as the
>> stranger does not need to provide all the attributes on the initial login
>> request (which they do with SAML (and OIDC?), as this leads to maximal
>> privileges).
>> Kind regards
>> David
>> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://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/20210517/037ecfd9/attachment.html>

More information about the Openid-specs-ab mailing list