Delegation and attenuation #229
Conversation
... but they may convey information so that a verifier may consider granting additional authority to a subject.
index.html
Outdated
| with if it is to accept the verifiable credential or verifiable | ||
| presentation. | ||
| If the verifier is not willing to accept or does not understand | ||
| these terms of use or then it SHOULD reject the verifiable |
There was a problem hiding this comment.
Good catch... in fact I don't think it needs the comma either. I pushed a commit removing the "or".
index.html
Outdated
| Terms of use describe policy describing how a | ||
| <a>verifiable credential</a> should be used or distributed. | ||
| For example, terms of use can be added to declare that a credential | ||
| should not be stored to a database or shared by a holder to another |
There was a problem hiding this comment.
stored to a database => stored in a database
holder to another => holder with another
There was a problem hiding this comment.
I disagree with this change as it has deleted important information. For example, it says nothing about adding terms of use to a verifiable presentation, which the original text did.
This is a regressive edit as it removes clarity.
There was a problem hiding this comment.
@dlongley okay I'll make those changes in a few
@David-Chadwick Good point, I'll add information about terms of use for a verifiable presentation.
There was a problem hiding this comment.
Okay. I pushed information about the verifiable presentation and also fixed the grammar nits. Hope that solves it!
Also give an example.
Too many "and"s!
| <a>verifiable credential</a> or <a>presentation</a> | ||
| should be used or distributed. | ||
| For example, terms of use can be added to declare that a credential | ||
| or profile should not be stored in a database or shared by a holder |
There was a problem hiding this comment.
I thought we were going to remove all reference to "profile" in favor of "presentation"
| </p> | ||
|
|
||
| <p> | ||
| A profile which wraps credentials must be interpreted of having |
There was a problem hiding this comment.
Same comment as above ("presentation" vs. "profile").
I am concerned about the casualness of the term "wrap" here. A presentation doesn't always contain or embed its source credential; it may instead derive from the credential. This means the terms of use are not naturally conveyed; this is the essence of Issue #224. I don't think we can simply assume that terms of use of a presentation are identical to terms of use of a credential.
There was a problem hiding this comment.
Possibly the "terms of use" as they are now being referred to should be a distinct payload (and I think, in fact, they are a secondary VC) -- so they may be transmitted and evaluated distinctly from the VC under immediate consideration.
I think also that atomicity of VCs is becoming important. Anything that may be presented as its own VC should be such at all times -- or it's a derived VC, which opens up questions about chains of verification, not too different from evaluating chains of TLS certificates. "A said 'B said ... "Q said R about S."'" The Receiver must potentially be able to track back and Verify each link in this chain.
There was a problem hiding this comment.
A few further thoughts about this...
A said B about C.
C is "A said D about E"
C is some description of E -- let's call it a medical test result, so it has HIPAA protections (in the USA).
B is a description of those HIPAA (or similar) protections -- who is authorized to act on C and in what ways (Read, Write, Share, etc.). In other words, B is a "terms of use" for C
B should somehow be evaluated before C... and if we're not careful, we're back into protocol discussions! ... but evaluating C is the only way to discover B... So perhaps anything involving terms-of-use should be a credential-of-credentials.
A said B and C. # credential-of-credentials
B is "A said D about C" # terms-of-use
C is "A said E about F" # test-results
Thoughts?
| But if Carol were found to not be in compliance there may still be | ||
| consequences. | ||
| For example, if Alice presented evidence to the medical board that | ||
| Carol violated these terms, Carol's medical license might be |
There was a problem hiding this comment.
I don't think this is technically true... the bar for medical malpractice is higher than that, I think. @agropper might know more.
| But if Carol were found to not be in compliance there may still be | ||
| consequences. | ||
| For example, if Alice presented evidence to the medical board that | ||
| Carol violated these terms, Carol's medical license might be |
There was a problem hiding this comment.
I don't think this is technically true... the bar for medical malpractice is higher than that, I think. @Gropper might know more.
|
We try to deal with this in HIE of One and I don't think policy or terms of
use has anything to do with it. The licensing boards and malpractice courts
do not specify policy. They are concerned with "standard of practice" and
specific regulations like HIPAA. Neither one is linked to policy in the way
that, for example, FTC enforcement is. FTC enforcement is based on
violating your stated policy regardless of what the standards of practice
are.
HIE of One is designed so that Alice can prove that Dr. Bob has certain
credentials and that the same Dr. Bob has signed a transaction involving
Alice. The signed transaction is hashed and posted to a blockchain to
enable such proof in a non-repudiable way. Dr. Bob's credentials are
therefore linked to the transaction they signed in a non-repudiable way and
the issuers of this credentials can revoke them or otherwise sanction Dr.
Bob if the transaction violates either standard of practice or the HIPAA
regulations.
Another issue has to do with the transaction involving a controlled
substance. In that case the regulations around issuance and use of the
doctor's DEA credential are stricter and Alice has to have a deduplicated
identity. I don't think that's relevant to this particular thread.
If this issue is about terms of use, I don't think medical use-cases are
particularly relevant.
Adrian
…On Tue, Sep 11, 2018 at 9:57 PM Manu Sporny ***@***.***> wrote:
***@***.**** requested changes on this pull request.
------------------------------
In index.html
<#229 (comment)>:
> + <p>
+ This example also provides a clear demonstration of why terms of
+ use are policy that an issuer must rely on external means for
+ enforcement.
+ Nothing about the transmission of this information with these terms
+ of use guarantees to Alice that their restrictions will be carried
+ out.
+ Furthermore, if Carol were a malicious entity, she could always
+ unwrap the individual credentials from the presentation and distribute
+ them independently and receiving holders and verifiers of those
+ claims might never know that Alice did not want Carol to distribute
+ them further.
+ But if Carol were found to not be in compliance there may still be
+ consequences.
+ For example, if Alice presented evidence to the medical board that
+ Carol violated these terms, Carol's medical license might be
I don't think this is technically true... the bar for medical malpractice
is higher than that, I think. @agropper <https://github.com/agropper>
might know more.
------------------------------
In index.html
<#229 (comment)>:
> + <p>
+ This example also provides a clear demonstration of why terms of
+ use are policy that an issuer must rely on external means for
+ enforcement.
+ Nothing about the transmission of this information with these terms
+ of use guarantees to Alice that their restrictions will be carried
+ out.
+ Furthermore, if Carol were a malicious entity, she could always
+ unwrap the individual credentials from the presentation and distribute
+ them independently and receiving holders and verifiers of those
+ claims might never know that Alice did not want Carol to distribute
+ them further.
+ But if Carol were found to not be in compliance there may still be
+ consequences.
+ For example, if Alice presented evidence to the medical board that
+ Carol violated these terms, Carol's medical license might be
I don't think this is technically true... the bar for medical malpractice
is higher than that, I think. @Gropper <https://github.com/Gropper> might
know more.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#229 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIeYUaD8HpaJ2OihEaSyAji6uAeFMa4ks5uaGn-gaJpZM4WiQvB>
.
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/
|
| Credentials are not themselves an authority mechanism, but are | ||
| intended to convey information that can be useful in evaluating | ||
| whether to grant additional authority. | ||
| </p> |
There was a problem hiding this comment.
I disagree with this change. VCs are not "who said what about whom" as this is no more than tittle-tattle or heresay. VCs are credentials, as their name implies. They are attributes about subjects issued by trusted (in the eyes of the verifier) issuers.
VCs are in fact an authority mechanism. A driving license is an authorisation to drive. A passport is an authority to leave your country of citizenship.
This change should be rejected as it gives an entirely wrong discourse about VCs, and in fact negates much of the earlier text about VCs
There was a problem hiding this comment.
VCs are absolutely "who said what about whom". (Well... they're not about the question "who said what about whom?", but about confirmation/verification that "A said B about C".) In other words, VCs must convey sufficient information to permit a Receiver to Verify the Subject (C) and Issuer (A), and to understand the Statement (B). Possibly the Receiver needs to be able to Verify that the Presenter is Permitted/Authorized to Present a VC of which they are not the Subject.
VCs let a border agent verify that a Passport -- a Credential which says CitizenOfNation (B) about Person (C) -- was Issued by the State Department (A) and is being Presented by that Person (C) -- via biometrics (height, weight, photo), embedded RFID, etc. Whether that Person is granted any authority (e.g., permission to cross the border) by virtue of this Statement is not part of the VCs remit.
VCs let a police officer verify that a driver's license -- a Credential which says LicensedToOperateSimplePassengerVehicle (B) about Driver (C) -- was issued by the relevant Issuing Authority (A) and is being presented by that Driver (C) -- via biometrics (height, weight, photo), embedded RFID, etc. Whether that Person is granted any authority (e.g., permission to drive this vehicle) by virtue of this Statement is not part of the VCs remit.
Current highly fallible verification is done using the characteristics of the presented document -- watermarks, holograms, overprinting, sample documents, etc. VCs are supposed to be less fallible because of the ability to do something (as yet indeterminate, because that's the protocol) with the observable/dissectable characteristics (which may include partially encrypted and indecipherable content/payload) of the VC.
"Tittle-tattle or hearsay," as you call it, would be unVerifiable Credentials -- where I show the border agent a document which says something like "the UN said TallTed is a citizen of Earth, and may travel freely across all national borders" -- or perhaps I simply say this. There is clearly no way to verify these credentials, because they convey nothing which might be used for such verification -- nor do they unambiguously identify me (Subject, and in this case, Holder).
| For example, a Verifiable Credential can be used so that Alice (a | ||
| <a>verifier</a>) can verify that Bob (an <a>issuer</a>) said that | ||
| Carol (a <a>subject</a>) was an experienced programmer. | ||
| Based on this information, Alice might hire Carol and from there |
There was a problem hiding this comment.
This is a facile example and downgrades the use of VCs from important use cases to less important ones. Whilst the example is true, nevertheless it should not be used as a guiding example of what a VC is. A more valuable example such as driving licence, address, passport of other credential should be used
There was a problem hiding this comment.
Facile examples help with comprehension, which these documents are substantially about. "More valuable" examples that are harder to explain and comprehend, with lots of extraneous detail (which may or may not be important in other scenarios) are part of the picture, but should not be the whole picture.
There was a problem hiding this comment.
The Use Case document includes a small set of "Focal Use Cases" that attempt to show more complex applications of VC. The DM example should be fairly simple, easy to understand, and not require insight to a particular industry or jurisdiction.
|
|
||
| <p> | ||
| The expression of terms of use may be performed via the following | ||
| <a>property</a>: | ||
| </p> | ||
|
|
There was a problem hiding this comment.
I do not think any of the above belongs in the data model document.
This is because the data model document should specify the following
a) its assumptions, limitations, constraints
b) its trust model
c) the data fields and their semantics (assuming a) and b) are satisfied)
There is no reason to specify in the document what might happen when any of the assumptions/constraints etc are violated by any of the actors. This is out of scope, since there are literally an infinite number of violations and possibilities that could take place once an implementation or usage scenario steps outside the constrained circle that is specified by the data model. All bets are off once the constraints are broken. Thus there is no reason or purpose in specifying any of these potential violations, including the above.
There was a problem hiding this comment.
I think this comment is going in the right direction, as was today's mention of the Data Model of X.509 Certificates -- which are, I think, a coherent and functioning example of a Verifiable Credential. Various uses of these Certificates (signing email, TLS-secured connections, etc.) are defined in various Protocols -- none of which are or were explicit parts of that Data Model, and all of which make use of that Data Model.
|
We might consider this wording in terms of the value proposition.
VC are valuable (at least in our HIE of One use-case) to the extent they
work in situations where federation doesn't work. Federation is limited by
the need to trust an identity provider intermediary which is costly and
privacy-invasive. In some cases, there is value in an intermediate
guarantor that carries liability relative to the verifiers and in other
cases, the intermediary is just a cost and a delay. This point was
extensively discussed at MyData 2018 in a session that had uPort, HIE of
One, and InfoCert as examples of real-world usage.
The words we use should clarify and be balanced with respect to this
distinction. The issuer of a credential is being paid up-front to make sure
that credential is useful in various contexts. The risk for how that
credential is used differs in the federated model vs. the self-sovereign
one but in neither case does the risk fall on the issuer.
If we do a good job with the wording, it should be clear that the issuer
always benefits from adopting VC. Verifiers have a choice of bearing the
risk themselves or transferring it to an intermediary certificate
authority. The subject is just paying the bills and hoping that the
regulations work for them.
Adrian
…On Thu, Sep 13, 2018 at 10:46 AM David Chadwick ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In index.html
<#229 (comment)>:
> @@ -793,6 +793,26 @@ <h2>Types</h2>
specification that want to support extensibility in an interoperable fashion do.
</p>
+ <div class="note">
+ <p>
+ It is important to note that the Verifiable Credentials data model is
+ intended to convey information about who said what about whom.
+ Credentials are not themselves an authority mechanism, but are
+ intended to convey information that can be useful in evaluating
+ whether to grant additional authority.
+ </p>
I disagree with this change. VCs are not "who said what about whom" as
this is no more than tittle-tattle or heresay. VCs are credentials, as
their name implies. They are attributes about subjects issued by trusted
(in the eyes of the verifier) issuers.
VCs are in fact an authority mechanism. A driving license is an
authorisation to drive. A passport is an authority to leave your country of
citizenship.
This change should be rejected as it gives an entirely wrong discourse
about VCs, and in fact negates much of the earlier text about VCs
------------------------------
In index.html
<#229 (comment)>:
> @@ -793,6 +793,26 @@ <h2>Types</h2>
specification that want to support extensibility in an interoperable fashion do.
</p>
+ <div class="note">
+ <p>
+ It is important to note that the Verifiable Credentials data model is
+ intended to convey information about who said what about whom.
+ Credentials are not themselves an authority mechanism, but are
+ intended to convey information that can be useful in evaluating
+ whether to grant additional authority.
+ </p>
+
+ <p>
+ For example, a Verifiable Credential can be used so that Alice (a
+ <a>verifier</a>) can verify that Bob (an <a>issuer</a>) said that
+ Carol (a <a>subject</a>) was an experienced programmer.
+ Based on this information, Alice might hire Carol and from there
This is a facile example and downgrades the use of VCs from important use
cases to less important ones. Whilst the example is true, nevertheless it
should not be used as a guiding example of what a VC is. A more valuable
example such as driving licence, address, passport of other credential
should be used
------------------------------
In index.html
<#229 (comment)>:
> + Under some schemes, if Carol were a malicious entity, she could
+ potentially unwrap the individual credentials from the presentation
+ and distribute them independently; receiving holders and
+ verifiers of those claims might never know that Alice did not want
+ Carol to distribute them further.
+ But if Carol were found to not be in compliance there may still be
+ consequences.
+ For example, if Alice presented evidence to the medical board that
+ Carol violated these terms, Carol's medical license might be
+ revoked.
+ </p>
+ </div>
+
+ <p>
+ The expression of terms of use may be performed via the following
+ <a>property</a>:
</p>
I do not think any of the above belongs in the data model document.
This is because the data model document should specify the following
a) its assumptions, limitations, constraints
b) its trust model
c) the data fields and their semantics (assuming a) and b) are satisfied)
There is no reason to specify in the document what might happen when any
of the assumptions/constraints etc are violated by any of the actors. This
is out of scope, since there are literally an infinite number of violations
and possibilities that could take place once an implementation or usage
scenario steps outside the constrained circle that is specified by the data
model. All bets are off once the constraints are broken. Thus there is no
reason or purpose in specifying any of these potential violations,
including the above.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#229 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIeYQjgQygAgaPrC07Dg9OK__sAFk_1ks5uam-0gaJpZM4WiQvB>
.
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/
|
|
I added several comments in thread-lines above... Just flagging so they're not overlooked because of github page presentation. |
|
I don't know where we are with this PR. It sounds like most everyone is fine w/ the PR except for @David-Chadwick? I don't know if @TallTed is agreeing or disagreeing with @David-Chadwick in certain instances? Help. |
|
@msporny -
I believe I was disagreeing with @David-Chadwick in every case here (and generally agreeing with the PR, as far as it goes). But if it appears otherwise somewhere, please flag the particular, so I can check it? I did have some disagreement with this (or perhaps a basis to start another) PR (I think), in my response to @dhh1128 here. |
|
@cwebber @David-Chadwick @TallTed -- I'm closing this PR in 48 hours for the following reasons:
If there are no objections to closing in 48 hours, I'll close it out. |
|
Ok by me to delete this one |
|
DO NOT MERGE - see if it is subsumed by another PR. |
|
This PR has been subsumed by PR #291 and many others that have noted that the spec is not an authorization mechanism in and of itself. Closing. |
Closes issue #72.
Preview | Diff