[Openid-specs-ab] SIOP, Trust Frameworks, and SSI/Open Source
david at alkaline-solutions.com
Mon May 17 20:48:52 UTC 2021
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.
> Kind regards
>> thx ..Tom (mobile)
>> On Mon, May 17, 2021, 9:36 AM David Chadwick <d.w.chadwick at verifiablecredentials.info <mailto: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
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab