Skip to content

Delegation and attenuation #229

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 11 commits into from
Closed

Delegation and attenuation #229

Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
692a741
Issue #74: Update information about how terms of use being policy
cwebber Sep 10, 2018
59c21b6
Verifiable Credentials are not an authority mechanism
cwebber Sep 10, 2018
37b0f01
Get rid of unnecessary or
cwebber Sep 11, 2018
d6aecd6
Mention that verifiable presentations can have termsOfUse as well
cwebber Sep 11, 2018
d39b959
Reordering of terms of use example sentences a bit.
cwebber Sep 11, 2018
5caf438
Correcting some grammar nits from @dlongley.
cwebber Sep 11, 2018
9a8a871
A couple more grammar fixes.
cwebber Sep 11, 2018
423301e
More minor nit fixing.
cwebber Sep 11, 2018
c19ff10
Some minor tweaks to the "if Carol were a malicious entity" sentence
cwebber Sep 11, 2018
97365c8
Use a semicolon to break up the sentence a bit more nicely
cwebber Sep 11, 2018
d23d50d
Add (back) a comma after malicious entity
cwebber Sep 11, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
125 changes: 102 additions & 23 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).


<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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

use another authorization mechanism to permit Carol to administer
her computers, but Bob saying that Carol was an experienced
programmer does not itself grant her the authority to do so.
</p>
</div>

</section>

<section>
Expand Down Expand Up @@ -1251,35 +1271,94 @@ <h3>Semantic Interoperability</h3>
<section>
<h2>Terms of Use</h2>

<p>Terms of use can be utilized by an <a>issuer</a>, a <a>subject</a>, or a
<a>holder</a> to constrain the use of information expressed by the Verifiable
Credentials Data Model. The <a>issuer</a> places their terms of use inside
the <a>credential</a> before it is converted into a <a>verifiable credential</a>.
The <a>holder</a> places holder terms of use inside a <a>presentation</a>.
<p>
Terms of use describe policy describing how a
<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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we were going to remove all reference to "profile" in favor of "presentation"

with another entity.
</p>

<p class="note">
From an information copying perspective, once information is shared
with a holder in an unconfined environment, it will always be
technically possible for that entity to share information, even
contrary to the intent expressed in the terms of use policy.
However, terms of use are still useful as an expression of what
policy participating parties are consenting to.
Well-behaving entities can use terms of use information to inform
their own behavior in regard to the information found in the
verifiable credential.
Enforcement can happen externally to an entity found in violation
of the terms of use: relationships or contracts could be severed,
trust could be lost, and in some cases legal action could be taken.
</p>

<p>
A profile which wraps credentials must be interpreted of having
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@TallTed TallTed Sep 25, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

its terms of use through aggregation of the respective credential
plus the wrapping profile.
</p>

<p class="note"> it is for further study how a subject who is not a
holder places terms of
use on his or her verifiable credentials. One way could be for the subject to
request the issuer to place them inside the issued verifiable credentials. Another
way could be by the subject delegating a verifiable credential to a holder and
placing terms of use restrictions on the delegated verifiable credential.
</p>
<p> The expression of
terms of use may be performed via the following <a>property</a>:
<div class="note">
<p>
As an example, consider a patient named Alice enrolling with a new
primary care provider, Carol.
She provides a presentation that aggregates proof of her insurance,
proof of her state identity, and her prior patient records from
her former primary care provider Bob.
On the presentation she sets the terms of use prohibiting third party
correlation for any of the data provided, and on her state identity
she prohibits archival of that information, since it is only needed
during initial enrollment.
This is useful because the issuers of the respective claims do not
personally require that this information not be correlated by a
third party, but this requirement is important to Alice.
Thus the terms of use require that Carol not correlate any of the
information provided with third parties for any of the information
provided in the presentation, but the state identity information must
additionally must not be archived.
</p>
<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.
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is technically true... the bar for medical malpractice is higher than that, I think. @agropper might know more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is technically true... the bar for medical malpractice is higher than that, I think. @Gropper might know more.

revoked.
</p>
</div>

<p>
The expression of terms of use may be performed via the following
<a>property</a>:
</p>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

<dl>
<dt><var>termsOfUse</var></dt>
<dd>The value of this property MUST be one or more terms of use
that tell the <a>verifier</a> what actions it MUST perform if it is to
accept the verifiable credential or verifiable presentation.
If the verifier is not willing to accept these terms of use then it MUST reject
the verifiable credential or verifiable presentation.
Each <code>termsOfUse</code> comprises its type,
for example, <code>IssuerPolicy</code>, and
optionally its instance id. The precise contents of each term of use is
determined by the specific <code>TermsOfUse</code> type definition.
<dd>
The value of this property is one or more terms of use that tell
the <a>holder</a> or <a>verifier</a> what policy it should comply
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 then it SHOULD reject the verifiable
credential or verifiable presentation.
Each <code>termsOfUse</code> value MUST have a type (for example,
<code>IssuerPolicy</code>).
The precise contents of each term of use is determined by the
specific <code>type</code> definition.
</dd>
</dl>

Expand Down