"Proof of Authorization to Update" vs "Proof of Control" #1
Comments
|
I think we need a list of clear, concise, concrete use cases that explain why "control", "ownership", "authentication", and/or "authorization to update" are necessary (and what they actually mean in a sensible context). It seems to me that we're also potentially conflating:
I have a lot of thoughts on the matter, but I'd really like to see the core use cases that are important to people to cover. The most clear use case for me is when a user visits a website where they want to authenticate as a particular entity. The purpose for this authentication is to obtain credentials or to present them so that the user can gain authorization to something else. This use case presents at least two requirements:
There is likely a third requirement that falls out of the second one (or that could be used as an alternative to the second one):
|
|
The "proof" sections in the example DDO should probably contain the proof(s) themselves (the proofs used to demonstrate a change to the DDO by particular author(s) is permissible). So that would mean we'd have something like this: Other formulations are acceptable obviously, but it seems like this would approach would make the names more appropriately match the relationship semantics -- and we'd get better differentiation on the concepts. We may need to combine proof types with entities in the authorization list for things like "multisig proof" to properly indicate which entities need to participate in the multisig. Again, figuring out what capabilities are needed requires articulating some concise use cases. |
|
@dlongley and I talked about this in the office this morning and as a result, I'm going to try to elaborate on all of the use cases in the Veres One DID Method spec by including examples here. If folks think this is a good direction, then I'll integrate them into the spec. Examples to follow... |
|
This DID Object expresses that any entity that submits a proof containing an RSA Signature with the key .../keys/2 is allowed to authenticate as did:v1:215cb1dc-1f44-4695-a07f-97649cad9938. {
"@context": "https://w3id.org/veres-one/v1",
"id": "did:v1:215cb1dc-1f44-4695-a07f-97649cad9938",
"authenticationCredential": [{
// this key can be used to authenticate as DID ...9938
"id": "did:v1:215cb1dc-1f44-4695-a07f-97649cad9938/keys/1",
"type": "RsaCryptographicKey",
"owner": "did:v1:215cb1dc-1f44-4695-a07f-97649cad9938",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}]
} |
|
This DID Object expresses three ways in which the writeAuthorization field may be used to update specific fields in the DDO
{
"@context": "https://w3id.org/veres-one/v1",
"id": "did:v1:215cb1dc-1f44-4695-a07f-97649cad9938",
"writeAuthorization": [{
// this entity may update any field in this DDO using any authentication mechanism
// understood by the ledger
"entity": "did:v1:215cb1dc-1f44-4695-a07f-97649cad9938"
}, {
// this entity may update the authenticationCredential field in this DDO as long as they
// authenticate with RsaSignature2017
"entity": "did:v1:b5f8c320-f7ca-4869-85e6-a1bcbf825b2a",
"field": ["authenticationCredential"],
"permittedProofType": [{
"proofType": "RsaSignature2017"
}]
}, {
// anyone may update the authenticationCredential and writeAuthorization
// fields as long as they provide a specific multi-signature proof
"field": ["authenticationCredential", "writeAuthorization"],
"permittedProofType": [{
"proofType": "RsaSignature2017",
"minimumSignatures": 3,
"authenticationCredential": [{
"id": "did:v1:304ebc3e-7997-4bf4-a915-dd87e8455941/keys/123",
"type": "RsaCryptographicKey",
"owner": "did:v1:304ebc3e-7997-4bf4-a915-dd87e8455941",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}, {
"id": "did:v1:0f22346a-a360-4f3e-9b42-3366e348e941/keys/foo",
"type": "RsaCryptographicKey",
"owner": "did:v1:0f22346a-a360-4f3e-9b42-3366e348e941",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}, {
"id": "did:v1:a8d00377-e9f1-44df-a1b9-55072e13262a/keys/abc",
"type": "RsaCryptographicKey",
"owner": "did:v1:a8d00377-e9f1-44df-a1b9-55072e13262a",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}],
}],
"authenticationCredential": [...]
} |
|
Let me give you some examples where proof of authorization is needed. Suppose I want to delegate authority to an entity (software, devices) to act on my behalf. A device with authorization shows that I have allowed it to be used by me. I can also revoke my authorization which is handy when a device is stolen. The same can be true for software programs. I authorize a software program to receive claims on my behalf but if that program begins to function in a way I disagree with then I can revoke its authorization. You can also tie authorization to epochs or access control. The concept is simple but very powerful and useful if we expect adoption. Here we are authorizing something or someone writeAccess to the DDO. We are using this to prove authenticity in the changes as well. Without it, the security and integrity of the system could be in jeopardy. |
Hey @mikelodder7, I agree with everything you said, which means I'm confused now. Are you saying we don't support what you're saying is important? Or were you just further reinforcing the points we were making via the data model above? |
|
I'm reinforcing your points by giving more examples of authorization. I think it should just be proof of authorization. I may need to do more than update. I may choose to allow delegates to do anything with the stipulation that I can revoke it later. Proof to update is a single use case where someone or something needs to update the DDO but what if you wanted them to have power of attorney or something else. No need to limit it to just updating. You're model is good for this particular use case. |
Got it, thanks for clarifying @mikelodder7. Pay particular attention to the This approach also allows us to add other fields to the DDO, such as |
|
I think that everyone has made good points, but there seem to be at least two issues in discussion here. The first is about semantics, i.e. what should we call these DDO properties? I don't think we can have a reasonable discussion about semantics until we've clarified usage. To use the terms from the [DID-Spec](https://w3c-ccg.github.io/did-spec/#dids-(decentralized-identifiers): |
|
I find it useful to adopt a strict definition of "owner" as the entity that can take something off-line or effectively delete it. In the DID / DDO context, that would suggest that anyone who can take a DDO off-line effectively owns it. Making changes to a DDO does not imply ownership since the changes can affect only a subset of the DDO. Ownership of a DID is a different matter. It's not possible to delete or take off-line a blockchain transaction but it is possible to "spend" it. By my suggested definition, nobody owns a DID. The entity that can modify a DID by "spending" it is not an owner of the DID, it's a controller, delegate, or trust, I guess. |
|
@brentzundel wrote:
Thanks for the feedback @brentzundel - from what you wrote, I think we agree on the purpose of the fields in the DDO, now it's just a "simple" matter of naming them (naming being one of the hardest things to do in Computer Science). :) If folks agree with the general premise of needing to separate how an entity authenticates itself as a particular DID from what they can do once they authenticate, then we basically have two MVP things that we need to name here:
We've considered naming things "proofOfXYZ" before and the strongest arguments against that path were:
You can use #1 to authenticate w/ the ledger (e.g. update the DDO) AND to authenticate w/ systems external to the ledger (e.g. login). You use #2 to primarily do things w/ the ledger (e.g. update the DDO, rotate keys as a guardian, etc.). Based on that line of thinking, we named #1 "authenticationCredential" because it's effectively a list of credentials (keys, pseudonymous biometric templates, ZKPs) that you can use to authenticate as the DID. We named #2 "writeAuthorization" because it's effectively a list of mechanisms (e.g. proof types) that, if fulfilled by a proof submitted to the ledger, are authorized to make updates to specific fields in the DDO. Hopefully that gives you more background on the logical progression of our thinking. We're not married to the names yet, so there is still time to change them (and even if we get them wrong, JSON-LD allows us to change them in the future even after the spec has shipped... but really, we don't want to do that and would like to nail these names down in the next month or so). |
|
@agropper wrote:
When we discussed (internally) using something like "owner", the following points were raised against its use:
I would argue that nobody owns a DDO either. A ledger "owns" a DID /and/ a DDO. A DDO specifies what types of proofs are required to authenticate, and what types of entities + optional proofs are required to modify certain fields in the DDO.
This presumes a ledger with a cryptocurrency, and two of the ledgers that we're talking about (Sovrin and Veres One) don't need a cryptocurrency to provide DID/DDO functionality. We should stop talking about "spending" as a thing as it's very specific to Bitcoin and Ethereum based solutions. We also need to be careful with "controller", "delegate", and "trust" as those can be slightly different concepts as well (and again, are more broad than they need to be). We need to be able to compose the low level security primitives we've created ("authentication" and "authorization to write to DDO") into these higher level concepts of "delegate", "guardian", and "trustees". Hope that helps clarify our thinking on this @agropper, let me know if there are parts that still don't gel or make sense with you. |
|
I'm ok with never using the word owner for anything. It's just that it
comes up so very often that I feel compelled to argue for a definition.
That said, let me react to some of the issues below.
inline...
On Thu, Aug 31, 2017 at 10:08 AM, Manu Sporny ***@***.***> wrote:
@agropper <https://github.com/agropper> wrote:
I find it useful to adopt a strict definition of "owner" as the entity
that can take something off-line or effectively delete it.
When we discussed (internally) using something like "owner", the following
points were raised against its use:
1. The word "owner" is not specific enough, which leads people to
create analogies that conflate "authentication" vs. "authorization", and
that harms ones ability to grasp what the field in the data model actually
does.
2. Using highly specific terms and functions enable us to build a
system that is more composable, which results in a more adaptable system as
time goes on. Owner doesn't not easily enable extensibility as there is a
hard line drawn "either you're the owner, or you're not". However, moving
to a model where you talk about capabilities that entities have (a
capabilities model) leads to an easier ability to delegate and compose
security in the system. That is, you want to be nuanced in how you use
various authentication mechanisms to work in concert with statements on
which entities are authorized to do what... and the concept of "owner"
unnecessarily conflates those two distinct concepts.
By my suggested definition, nobody owns a DID.
I would argue that nobody owns a DDO either. A ledger "owns" a DID /and/ a
DDO. A DDO specifies what types of proofs are required to authenticate, and
what types of entities + optional proofs are required to modify certain
fields in the DDO.
There's no doubt as to whether something can be taken off-line or not. If
there's a pointer on a public ledger (e.g.: an IP address or URL) and that
pointer goes dark, then whatever was there is gone. Content-addressable
routing is a special case of pointers where obviously the content cannot be
taken down under normal circumstances.
The entity that can modify a DID by "spending" it is not an owner of the
DID, it's a controller, delegate, or trust, I guess.
This presumes a ledger with a cryptocurrency, and two of the ledgers that
we're talking about (Sovrin and Veres One) don't need a cryptocurrency to
provide DID/DDO functionality. We should stop talking about "spending" as a
thing as it's very specific to Bitcoin and Ethereum based solutions.
I completely agree. I used "" around spend to stand-in for various schemes
that enable key rotation and recovery around public ledgers. Sorry for the
confusion.
We also need to be careful with "controller", "delegate", and "trust" as
those can be slightly different concepts as well (and again, are more broad
than they need to be). We need to be able to compose the low level security
primitives we've created ("authentication" and "authorization to write to
DDO") into these higher level concepts of "delegate", "guardian", and
"trustees".
I agree here as well. I'm involved in numerous standards groups that
struggle with this delegation issue for many years. That includes a couple
of groups in Kantara as well as OpenID/HEART and even IEEE. Lawyers are
often involved, They come and go. I'm not aware of progress in this area.
Hope that helps clarify our thinking on this @agropper
<https://github.com/agropper>, let me know if there are parts that still
don't gel or make sense with you.
The EU regulatory distinction between "controller" and "processor" is
potentially useful. It tends to be missing in the US regulatory context
which complicates things a lot.
The state-of-the art, IMHO, is this recent 494-page drop from NIST
https://www.nist.gov/news-events/news/2017/08/nist-crafts-next-generation-safeguards-information-systems-and-internet
The
Glossary alone is 24 pages. It makes me want to move to a deserted island.
Can we scope what we're doing relative to the broader 494-page picture in
the US and whatever the equivalent might be in the EU? Unfortunately,
that's a very big job.
Adrian
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIeYXTrPNeetDaYDP2N2S8WpwoqSSpPks5sdr5OgaJpZM4PD3SP>
.
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
|
|
From the early days of DID/DDO design I think I remember that originally we assumed the keys for ledger transactions would be completely independent from the keys for the DID/DDO. Therefore we needed something like the "control" block, where any external observer could determine if a new DDO on the ledger is valid and therefore correctly supersedes the previous DDO on the ledger or not. Now instead we have a situation where in the common methods so far (btcr, sov, uport) the keys for ledger transactions are more or less directly linked to (or even the same as?) the keys for the DID/DDO. Doesn't this mean that the ledger itself and its method-specific resolution logic determine the rules according to which a DDO can be changed, and what types of proofs are supported? So if all this is enforced internally by the method anyway, why include a "control" block in the DDO at all, can't we just omit it? Same for "guardian". Take uport for example, "control" of DDO is basically determined by an Ethereum smart contract. Do you now want to define an RDF/JSON-LD vocabulary that captures the full expressiveness of that smart contract logic, just so you can include it in the DDO's "control" (or "writeAuthorization" or whatever) block? I think this means that "control", "guardian" etc. are only needed for logic that's not already inherent in the ledger-specific method anyway? |
Keep in mind that "originally" and "early days" is 2014 to a number of us... :) (or earlier if you count the WebID TLS and Mozilla Persona days): http://manu.sporny.org/2014/identity-credentials/ There was a time where much of what we are working with today was based on DHTs and Telehash and in that world, keys for updating the DDO were an integral part of the DDO. Even today, there are implementations, such as Veres One, where we specify the keys that are capable of modifying the DDO in the DDO. I do realize that others like BTCR and at least one of the Ethereum implementations, since those ledgers aren't specifically designed for DIDs and DDOs, have a more complicated mechanism for ensuring proper updating of the DDO and those keys often live outside of the DDO. Just level setting in order to address some of the other comments you've made. Originally we assumed keys for "ledger" transactions were part of the DID/DDO.
Yes, and in some cases, a fit-for-purpose ledger (like Veres One) expects that information to be in the DDO. I'd argue that it's a much simpler design, but understand that not all DID Methods can do this (some Bitcoin (BTCR) and Ethereum-based solutions, for example).
What you say is true, but I don't know if this is always going to hold. For example, one could imagine a solution where you specifically want to keep a set of keys for managing any DDO separate (for example: keys used by a regulator or employer to override anything the DDO says for ledgers that are not self-sovereign).
A few thoughts, some of which may be less compelling than others:
That could be one way to do it, if the uPort folks feel there is value there. I don't think one would try to encode the entire smart contract as JSON-LD, but merely the algorithm (like some ERC-20-like declaration might be enough with the definition of a few inputs). If not, they don't have to do it and the uPort DID Method would specify the other mechanisms for controlling the DDO, but again, this isn't as flexible is being declarative about the algorithms that you're using for control in the DDO.
For BTCR and uPort, that's probably true for this revision. I don't know if it'll hold in the future as other control and guardian algorithms are designed and deployed. For example, for the uPort implementation one may want back-references from the DDO to where to the contracts that control a DDO instead of having to scan the entirety of the Ethereum ledger. For Veres One, "control" and "guardian" are an integral part of the DDO as the ledger is specifically designed to pay attention to those fields and there is not much else that goes into the ledger (since it's fit for purpose). That is, all of the control logic in Veres One is declarative. So, I agree that your logic is sound for some of the ledger in use today. I'm uncertain if it works as the ecosystem expands to other ledgers and as uPort, BTCR, and Sovrin are upgraded as the years go on. We need to ensure that we don't make decisions that prevent us from extending and upgrading the systems in the future. |
|
Earlier @msporny, @ChristopherA and I discussed the BTCR spec and agreed that the current form is too method-specific and not sufficiently declarative. I took a stab at reformulating it in the structure that Manu has started above (below). First some notes and questions. I think this approach works well with BTCR and it nicely forced some editorial decisions. If we miss any of the dropped fields (e.g. varieties of transaction encoding, etc, which are easily derivable and probably not essential) we can include them in the method-specific spec. Question 1:
Question 2: BTCR DDO Using Above ApproachThis example will assume the BTCR transaction references what we call a DDO "fragment" or "continuation" DDO in IPFS. We'll first look at the fragment and them how it manifests in the final, derived DDO. DDO Fragment in IPFSThe following DDO fragment is stored in IPFS, and the address of this is stored in the OP_RETURN field of the BTCR transaction. This optional IPFS DDO fragment states:
Details about placeholder idsBecause changing the content changes the address, and because the DID depends on the Bitcoin transaction reference, we have a bootstrapping problem. We are using It's significant that this specific example uses IPFS. Because the content is immutable, the transaction signature signs the content hash as well. If not using content-addressable store, then another LD signature scheme would be used. BTCR Transaction and Derived DDOSuppose the Bitcoin testnet transaction is issued, resulting in the BTCR DID:
|
|
Here's another take on this with some slight changes. Specifically, I've moved the "capability" into a separate property within the more general "authorization" property. So "writeAuthorization" becomes "UpdateDdo" as a capability within authorization. I've also added "IssueCredential" as a separate capability with a specific restriction on the key that can be used to issue credentials where the issuer is "did:v1:215cb1dc-1f44-4695-a07f-97649cad9938" (the DID for this DDO). {
"@context": "https://w3id.org/veres-one/v1",
"id": "did:v1:215cb1dc-1f44-4695-a07f-97649cad9938",
"authorization": [{
// this entity may update any field in this DDO using any authentication mechanism
// understood by the ledger
"capability": "UpdateDdo",
"entity": "did:v1:215cb1dc-1f44-4695-a07f-97649cad9938"
}, {
// this entity may update the authenticationCredential field in this DDO as long as they
// authenticate with RsaSignature2017
"entity": "did:v1:b5f8c320-f7ca-4869-85e6-a1bcbf825b2a",
"capability": "UpdateDdo",
"field": ["authenticationCredential"],
"permittedProofType": [{
"proofType": "RsaSignature2017"
}]
}, {
// anyone may update the authenticationCredential and writeAuthorization
// fields as long as they provide a specific multi-signature proof
"capability": "UpdateDdo",
"field": ["authenticationCredential", "writeAuthorization"],
"permittedProofType": [{
"proofType": "RsaSignature2017",
"minimumSignatures": 3,
"authenticationCredential": [{
"id": "did:v1:304ebc3e-7997-4bf4-a915-dd87e8455941/keys/123",
"type": "RsaCryptographicKey",
"owner": "did:v1:304ebc3e-7997-4bf4-a915-dd87e8455941",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}, {
"id": "did:v1:0f22346a-a360-4f3e-9b42-3366e348e941/keys/foo",
"type": "RsaCryptographicKey",
"owner": "did:v1:0f22346a-a360-4f3e-9b42-3366e348e941",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}, {
"id": "did:v1:a8d00377-e9f1-44df-a1b9-55072e13262a/keys/abc",
"type": "RsaCryptographicKey",
"owner": "did:v1:a8d00377-e9f1-44df-a1b9-55072e13262a",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}]
}]
}, {
// this entity may issue credentials where the "issuer" field is this DDO's DID
// as long as this specific RSA key is used
"capability": "IssueCredential",
"entity": "did:v1:215cb1dc-1f44-4695-a07f-97649cad9938",
"permittedProofType": [{
"proofType": "RsaSignature2017",
"authenticationCredential": [{
"id": "did:v1:215cb1dc-1f44-4695-a07f-97649cad9938/keys/1",
"type": "RsaCryptographicKey",
"owner": "did:v1:215cb1dc-1f44-4695-a07f-97649cad9938",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}
}]
}],
"authenticationCredential": [...]
} |
|
Another option is to include an Of course, this requires standardizing around the meaning of those levels. There are some FIPS/NIST/FIDO/etc specs that talk about such levels but in slightly different ways or perhaps without a sufficient level of granularity for certain use cases. The approach may also introduce a further need for "proof of assurance level" -- that the level should be trusted as specified (via, e.g. TPM) rather than simply user declared. Specifying the individual authentication credentials required would maximize granularity but makes it more difficult to update/manage changes to authentication credentials. However, it may be the better choice here. |
|
Hey @kimdhamilton, just getting back to you on the question you asked above (thanks for the BTCR write-up, btw, super helpful): @kimdhamilton wrote:
I think there are at least two schools of thought on how to proceed:
I personally prefer the former, and it tends to be how things are done at IETF and W3C and supports more decentralized innovation. |
|
@kimdhamilton wrote:
Instead of using a microsyntax there, just omit it. It's perfectly valid to have a Linked Data object with no identifier. This is called a "blank node" and is the way you say stuff like "I don't know the identifier for this thing yet, but it definitely has these attributes". Doing this may create some attack vectors, so please do a thorough security analysis on it. @dlongley might have some thoughts on DDOs that temporarily don't have identifiers. In general, as long as everything is content addressed, and where the event order is anchored in a Blockchain, you should be good. I think the attack you might want to explore is what happens if someone detects the initial DID-less DDO and submits something to the Bitcoin blockchain simultaneously claiming the DID in the same block. Could there be a sleeper cell attack there? Is the worst that an attacker can do is make it indeterminate as to who owns the DID? My read on your approach says "No" to both cases because the DID is based on a combination of the transaction ID as well as the key information? I don't know enough about the details to do a thorough attack analysis. |
|
Thanks @msporny, I will open issues to:
|
|
You had asked what the core problem was that we were trying to address in this issue on one of the CCG calls. I think it boils down to a problem where there's a distinction without a real difference in the current DID spec:
Not only are both of these terms ("ownership" and "control") confusing, there is currently no actual difference (despite the spec stating so) because of a lack of granularity and a conflation of authentication and authorization. In concrete terms, anyone that can demonstrate "Proof of Control" can update the DDO to make themselves an owner -- therefore enabling them to establish "Proof of Ownership". There is certainly a use case where we want to allow third parties to add new authentication credentials on behalf of the DID "owner", however, indicating that there is a difference between Proof of Control and Proof of Ownership without a sufficient level of granularity to actualize that difference is misleading. Therefore, in this thread we have attempted to establish a capability-based model for more granular and clearly separated authentication and authorization. In this model you can specify which parties are authorized to modify particular parts of a DDO. Furthermore, it enables the specification of required levels of assurance via particular authentication credentials. These credentials must be used to authenticate the parties that designate what specific parts of the DDO they wish to update. |
This is more of a question, and likely something we will address in the coming weeks.
In the BTCR hackathon, we observed we needed more fine-grained categories than "Proof of Ownership" vs "Proof of Control". This is described here and (I think) some other issues.
What's called "Proof of Authorization to Update" here appears to match the definition of "Proof of Control" from the DID spec -- i.e. ability to update the DDO. And "Proof of Control" here seems to match the definition of "Proof of Ownership" in the DID Spec.
To clarify, this is my understanding of how the words are used in the DID Spec vs Veres 1 Spec:
I'm opening this issue not as a bug, but instead to track these terms as we decide the right names and categories for key/proof types.
"Proof of Control" from the DID spec has caused a lot of confusion -- i.e. without context, it's not clear how it differs from proof of ownership. I prefer something precise, like "Proof of Authorization to Update" used here.
The text was updated successfully, but these errors were encountered: