RFC010 multi vendor

[woutslakhorst]

RFC010 defines how a DID subject can authenticate with another DID subject when the DID subjects are, in fact, the same organization.

Closes #18

[reinkrul]

explain what is identified here, something like;

Since identification of the care organization within the OAuth flow

[woutslakhorst]

Switched to subject and added subject to terminology

[reinkrul]

This can be done by adding the DID of one document and add it to the other

"adding the DID of one document" already implies implementation, so I'd use "referring" in this sentence, since the implementation is defined in the next sentence (using alsoKnownAs)

This can be done by having the DID documents of the SaaS providers refer to each other.

[reinkrul]

The node operator MUST remove a DID from the alsoKnownAs field when the authentication or controller field changes in the referenced DID document.

I find it a bit hard to read without a concrete example (say vendor Alice and Bob or A and B), but if I understand correctly if A refers to B's DID using alsoKnownAs, A MUST remove the alsoKnownAs referral to B when B changes its authentication or controller key, regardless there was an attack or not?

[woutslakhorst]

That's correct and it's quite harsh. I'm not sure if it's needed. We should discuss it.

[stevenvegt]

Perhaps elaborate the problem and solution here a bit more explicit. Talk about te trust relation between node provider and care provider. Than explicitly introduce the solution this RFC will be about:

This RFC introduces a solution where DID documents refer to each other using the also-known-as propertie.

[stevenvegt]

Perhaps explain why each saas provider has their own DID document? I suspect it has to do with the coupling between document and services which are vendor specific?

[stevenvegt]

So, why do we nog require the other document to point back?

[woutslakhorst]

Why would we? Relations are unary in data transfer between custodian and actor. The custodian needs to trust the actor.

The other way around could be needed to signal the actor that there's data available on another node. That could be a recommendation not a necessity.

[stevenvegt]

The other document is just a number until it has VCs. Why not check fot those? This also prevents typos were the wrong documents are coupled and everything is mixed up.

[woutslakhorst]

This spec only defines the underlying mechanism for authz/trust. Specifications of VC's could define the automatic additions of synonyms when data of the VCs match.

[stevenvegt]

This all feels very error prone. I would like to hook in to existing processes like revoked VCs for example.

[woutslakhorst]

This spec has nothing to do with VCs. This point was added to detect compromised DID Documents and protect the custodian automatically. Automatic synonyms via VCs could potentially mitigate the problem of user intervention.

[woutslakhorst]

Will change node operator to node, since it's the software that should do it.

[stevenvegt]

I thing this document describes a specific subset where the care provider does not administers its own DID document. I think we should add that case here as well or make it explicit that it is about delegated identity.

[woutslakhorst]

It's still valid for when an care organization manages its own keys. They will probably not use the functionality. The only thing this spec defines is that data MUST be accessible for DID subjects that refer to each other using the also-known-as property.

[woutslakhorst]

This mechanism poses a security risk through fishing. Giving access to data must be supported with a piece of crypto (VCs). The idea for creating synonyms is OK, but it must be done in a different way.