A moderate rework of the introductory text and images #56
Conversation
Fix glossary linking issues.
|
Ok, this is ready to be reviewed. It's far from perfect, but what I think we're going for here is "good enough for a FPWD". I didn't touch the Data Model section at all, and just updated the titles of the "representations" sections. If you want to preview a live version of the document, it can be found here (note images won't be visible because of a bug in htmlpreview.github.io): |
|
The use of email as the first example claim jumped out a bit. Although we can put an email in a claim, an email on its own isn't generally a statement about a subject. An email address's primary purpose isn't to identify ourselves to online services (it's to provide a service endpoint for receiving messages), and when we do, that's us making a claim about ourselves, i.e., that we are the person at that email address rather than than someone else claiming that we are that person. I think, in fact, an email alone can't be a claim without an additional subject and issuer, in contrast to the other examples which more clearly communicate the pattern of an authority making a claim about a subject. Since we have three other examples in that section (which is repeated in the abstract and the introduction), I'd suggest we drop it. |
index.html
Outdated
| various online services. For example, we use | ||
| email addresses to identify ourselves to online services, | ||
| driver's licenses to prove that we are capable of operating a | ||
| motor vehicle, university degrees to prove we are well-trained |
index.html
Outdated
| driver's licenses to prove that we are capable of operating a | ||
| motor vehicle, university degrees to prove we are well-trained | ||
| and knowledgeable, and government-issued passports to travel | ||
| between countries and access financial services. It is the |
There was a problem hiding this comment.
The lead in sentence for this section indicated that we use claims to gain access to online services, yet, this following sentence that is meant to enumerate examples of that -- actually enumerates examples of non-online services and regulatory compliance. We should change the lead in:
"We use claims made by others about us to gain access to services or to prove our compliance with rules and regulations."
But that last bit is too formal for this introduction. I'll have to try and think of a more colloquial way of saying that.
There was a problem hiding this comment.
Opening the document with a promise to "gain access to various online services" seems like the antithesis of what our goal and charter is. That smacks of "credentials = authentication" and it makes me fairly uncomfortable. It doesn't set the right context for what we're actually doing.
The rest of the paragraph is better -- proving we can drive a car, being well trained and knowledgable, travel between countries, and access to financial services are great.
How about striking "We typically use claims made by others about us to gain access to various online services" and replacing it with:
Regardless of the digital or physical space, nearly every interaction where one individual is asking another for permission, access, or a benefit relies on trust and the ability of the individual to make a claim that the other can verify.
index.html
Outdated
| between countries and access financial services. It is the | ||
| goal of this specification to provide a standard way to | ||
| express these sorts of claims on the Web in a way that is | ||
| automatically verifiable. |
There was a problem hiding this comment.
automatically verifiable ... I don't think it's clear what's being verified. We need language that is more like:
"express these sorts of claims on the Web such that their authorship can be cryptographically verified."
index.html
Outdated
| and knowledgeable, and government-issued passports to travel | ||
| between countries and access financial services. This specification | ||
| provides a standard way to express these sorts of claims on the Web in | ||
| a way that is automatically verifiable. |
There was a problem hiding this comment.
Just a note here that whatever changes we make in the abstract need to be copied here.
I don't disagree with you and @dlongley is working on a reword of the text that might make more sense. Some background: When a website asks you for your email address, they're doing at least one thing: Asking how they should get in touch with you. They may also use that information to create a database record for you (even though that's a horrible design). Email today, is self-reported. The website has no idea if that's a valid email address unless they email the address and get a response with a valid token. In fact, this is what most sites to today and is one of the reasons "Login with Facebook" and "Login with Google" have become popular. They don't need to implement email address verification as Google/Facebook has done it for the website maintainer. An email verifiable claim serves the same purpose. For example, you can have a claim that says: "The entity with
That's true, but in some cases, since |
|
In the group calls there had been discussion about reviewing the terminology. We did some of that in the "identity" PR. Is this PR an appropriate place to review the terms defined in the introduction? In particular, both holder and issuer feel like a mismatch for the important characteristics of those roles. For "holder", it's not clear to me what control means without bundling it into a specific control mechanism such as a specific DID method. In the Joram engagement model, Joram never technically "held" any particular claims in any digital/physical sense. Nor did he fully control their creation (once he authorized a steward by giving them a pairwise identifier, the steward then issued the claim and recorded it in the datastore). Like most distributed systems, that data store was never "held" by any single individual. The defining role for Joram was two-fold. First, he coined pairwise identifiers so that stewards could create claims with him as a subject without using a common, correlatable identifier. Second, he presented claims made by one steward to other stewards to access services such as healthcare. One presumption baked into our discourse is that the presenter of a claim is the controller of that claim in some manner other than its presentation. I think this is often the case--especially when using public keys and DIDs to prove control of identifiers, but there's nothing innately wrong with presenting a claim which stands on its own without proving that the presenter controls it. For example, presenting a claim that encompasses my driver's license with enough biometric information (picture, height, etc.) such that the inspector can verify the authorship of the claim (the DMV) and separately correlate the biometric with my physical person. In this use case, its irrelevant whether or not I control the private half of a key pair. The claim/credential itself provides everything needed to be useful. Instead of "holder" and "control", I'd suggest "presenter" and "offers":
For "issuer", I think the important role is not the mechanics of issuing, but rather the authority of the statement. Anyone can be a legitimate issuer and anyone can make a statement about someone on their own authority. However, when we evaluate a potential claim, the relevant question is not whether or not someone is a legitimate issuer for that particular claim (the mechanics of issuing aren't subject to questions of legitimacy other than technical corruption). Rather, the important question is whether or not the statement maker is a legitimate authority for the statement. This is a key distinction from the legacy discourse around self-issued claims. In many circles, while such claims were valid mechanically, the issuer wasn't recognized as a legitimate authority. As such, support for self-issued claims never really took off. With verifiable claims, we not only enable claims from any source--including self-issued claims--we can co-opt the legitimacy of existing authorities in a way that previous identity/attribute architectures did not. By focusing on the embedded question of legitimate authority, I think we highlight both the fluidity of an open approach while embracing the value of existing authorities to participate in the claims ecosystem. Also, I don't think the transmittal of the claim is innate to the role of the authority/issuer. You could easily imaging such claims being created and then made available at a well-known URL. Instead of "issuer", I'd suggest "authority" and remove "transmittal"
|
|
@msporny On today's call, you mentioned that "holders" also receive claims, but I don't think that's innate to the architecture. In Joram's case, all the claims were stored in the distributed store. In many cases, I think even the JSON-LD that is the claim or credential will never actually be held by the "holder", as a DID or other URL would suffice for presenting the claim to an inspector. I understand that in many cases, the "holder" may also want to verify the claim is what they think it is, but in that case the functional role is that of "inspector". There isn't an innate requirement for a holder to verify the claim and it would muddy the water if everything an inspector can do we attach to the holder. Could you unpack what you meant on the call? |
|
@jandrieu with respect to the term holder... there are often challenges inherent in using generic and abstract terms and the case is no different here. In the professional licensure case, a governing body defines license requirements, a professional completes the requirements and earns status in the license, and a prospective employer confirms the professional is in good standing. Whether the professional ever holds a physical or digital artifact representing status isn't material, the professional "holds" rights to the benefits and privileges of status and holds control over access and sharing destinations. They are the primary invested party in that discrete fact. When we had the initial debate on vocabulary, this is how I rationalized the term "Holder" as it pertains to the space I have experience. |
|
@stonematt said:
Nope, you did the right thing. The wording, while accurate, is still a bit hard to navigate (being the opening sentence)... can you make another pass to try to break what you're saying into multiple short sentences... attempt 5th grade reading level. |
|
@stonematt said:
This is close to how I rationalized the term "Holder" as well. |
|
The thing that's holding this PR up at this point is the terminology, so I expect much of the rest of this thread to focus on the terminology we're using in the terminology and diagrams section. @jandrieu have you seen our detailed ecosystem diagram yet? This may shed some light on the other terms we are using: https://docs.google.com/drawings/d/16IalLHZZq5_PxMLh45EjhxsMcOTE6869PUSlybjDsoc/edit |
Current State
Proposal 1Issuer remains unchanged. So:
This would align our terminology with the way Jan Camenisch's group at IBM views a privacy-preserving identity architecture (see page 4): http://dl.ifip.org/db/conf/idman/idman2013/CamenischDLNPP13.pdf Proposal 2Issuer remains unchanged. This would address the term that most folks have had an issue with while leaving the other two in place, which folks seem to not have too much of a concern over. I think the level of concern is highest on Holder, followed by Inspector, followed by Issuer. |
|
I'm ok with using User to replace Holder. It's a fairly common term of art in the industry and, I think, it represents the appropriate party here. One side note: We've shied away from using the language "user centric" because it's become ambiguous, but it's worth noting that people who are drawn to user centric systems would notice that User does appear in the center of our most of our diagrams should we adopt it (which I think is a plus). I'm not suggesting we start using this language again -- just pointing out a minor advantage for people exploring our literature for the first time. I'm not too keen on switching Verifier and Inspector but I don't have strong feelings about it. We currently have a number of roles: Issuer, Holder, Inspector and a number of software tools: Identifier Registry, Repository, Verifier. It seems to me that the name Verifier fits more cleanly with a software tool than Inspector, which sounds, appropriately, like a role. An Inspector plays the role of someone who requires a verifiable claim from the User/Holder and they may use a Verifier as part of their inspection process. |
|
I suggest that we could probably talk about the entire verifiable ecosystem and the vast majority of the use cases using just three roles:
A Verifiable Claim is an assertion that can be presented to an Inspector by a party other than the Issuer such that the Inspector can cryptographically verify its authorship and integrity. But there is more to making the transfer or sharing of a Verifiable Claim meaningful, privacy preserving, and respectful:
I think, in the vast majority of cases where privacy matters, the Issuer enters into a relationship with the Subject, a human being, that enables them to make an assertion about the Subject. This assertion is made confidentially but shared as a Verifiable Claim with the Subject to expressly grant them the ability to prove this assertion was made. This act inherently transfers all rights to the Subject to decide with whom and under what conditions that claim may be shared and used. The only right the Issuer retains is the ability to revoke their assertion. This means that, usually, all rights, including the right to present, fall to the Subject. That it may be that a Subject, for legal purposes or otherwise (e.g. the Subject has no agency), grants these rights to a guardian/steward/holder is a separate concern with respect to understanding the main roles in the ecosystem. So I recommend that we strike the term "Holder" as a major role and instead use "Subject" wherever "Holder" is currently in use. A simple note, in one place in our specifications, can cover the special cases where the "Subject" has no agency or has transferred rights to some other party to act on its behalf regarding the transfer of Verifiable Claims. In fact, in a technical document, the entire "rights" section should fall under privacy considerations which, in my view, is further evidence that we ought to be focusing on "Subject" in our technical explanations. This is not meant to indicate that "rights" are not important (far from it), but in explaining the most basic technical details of how claims are made and flow through the ecosystem, creating new roles to cover special circumstances is a hindrance to understanding. |
|
BTW, I used the terms in the updated intro text. When we settle on the new terms, we'll want to update the language in this checkin: b901e99 |
|
I would like to make the following points:
|
|
D. Longley said
My comments on these are
|
I was trying to avoid using Subject there because it could be the Holder and I was fleshing out my argument that we should only deal with Holder as a special case. Calling it out as the Subject there seemed to assume away the point of contention. But, yes, my argument followed that this party is almost always the Subject. Anyway, that's the reason why Subject was not used there.
It's fine for those use cases where the Presenter is the Subject. But there may be some other mechanism that could prove to the Inspector that the Presenter had the right to present the claim -- and as I was trying to lay things out at a high, abstract level, I didn't want to get that specific. PoP is certainly a term we ought to use for a majority of use cases (and I believe we have been in discussion but perhaps not enough in our specifications).
I did not mean to imply the Issuer had to confer the rights. I was referring to the Subject there. In my later comments, I mention that as soon as the Issuer creates and transfers the claim to the Subject, that "This act inherently transfers all rights to the Subject to decide with whom and under what conditions that claim may be shared and used." I was trying to point out that a part of this ecosystem (and our data modeling) may be to define a language by which Subjects may express their terms of use when sharing with an Inspector. |
|
In reply to Dave Longley |
I do think that's important to deal with, but my main argument in this thread is that we don't need (or want) to involve that particular use case in our simplest explanations of the main roles in the ecosystem. I think it brings in unnecessarily complexity; we should talk about that use case, but as a special case rather than trying to integrate it into our main explanations and diagrams. I think Subject is sufficient.
Agreed.
I don't think using that term is in dispute (though I wouldn't call "delegation of authority" a technique -- as the technique would be the specific way you delegate authority, but that's a nit).
PoP is one way to go. There's no reason to assume that there won't be other methods used in the ecosystem. It's important that we communicate the need for such a mechanism upfront, but the details of any particular mechanism may be buried a little deeper -- or may even be considered out of scope for the WG other than as a recommendation.
This is just one technique for implementing DoA. There are many others. For example, a proof of control, perhaps given according to a DID specification, may be sufficient evidence to an inspector to accept the Subject's VC when submitted by the Holder. This is a useful exchange, but I do worry we're getting far afield from the goal in this particular thread. We're trying to figure out what edits to make to the spec prior to FPWD -- and I believe the main goal now is to determine what to do about the term "Holder". I am arguing we should simply replace it with "Subject" (which I believe to be a non-controversial term) and then add an issue to the spec to figure out a term for "Holder" for the special case where the presenter of the VC is not the Subject. Its usage is only for a special case of the typical VC flow. |
|
Dave Longley said Ans. If the holder can prove control of the private key of the subject, then they are in effect the subject. In which case they could also delegate to themself the privileges of the subject. So DoA could effectively cover this case as well. "I am arguing we should simply replace it with "Subject" (which I believe to be a non-controversial term) and then add an issue to the spec to figure out a term for "Holder" for the special case where the presenter of the VC is not the Subject. Its usage is only for a special case of the typical VC flow". Ans. I am happy to support this change of terminology |
|
I am extremely late to this extremely long thread, but I wanted to share an observation that I discussed with Joe Andrieu recently: over the last six months, I'm see the term "relying party" being used almost everywhere in the industry. OTOH, the term "inspector" seems highly specific to the VCWG. At the risk of reopening old wounds, can I ask why the VCWG isn't using "relying party"? |
Here is the definition of Relying Party from the OpenID Connect spec:
My recollection from the last time we had the discussion was that "Relying Party" was heavily associated with the OpenID flows and there was an understanding that a RP would talk directly with an Identity Provider (which is a trust violation). The other issue with "Relying Party" was the assumption that there is a Secure Token Service operating (and it would be a stretch to say that a Verifiable Claim is issued via a Secure Token Service). In addition, Microsoft's definition of Relying Party tends to be way more specific than what that role does in the Verifiable Claims ecosystem: https://msdn.microsoft.com/en-us/library/ee748466.aspx?f=255&MSPPError=-2147217396 It is true that most everyone uses Relying Party to talk about something "Inspector"-like in these scenarios, but what comes along with that is baggage related to not understanding the separation that Verifiable Claims provides between the IdP and the RP. Here are the high level differences between a Relying Party in the more traditional (OpenID) sense and the VC Inspector:
So, in short, there was concern over the baggage associated with Relying Party as it's been used in OpenID Connect. |
|
I see the concern re: OAuth, but what about the recent docs from NIST and
ISO? Both use the term relying party but I don't think are Oauth.
…-- Christopher Allen [via iPhone]
|
|
Manu, while I get all that, ironically your answer almost seems to prove my point. Literally everyone is using the term "relying party" for "the third point on the triangle", i.e., the party that relies on the the results of the protocol—in this case the delivery of a verifiable claim. Furthermore, as Christopher points out, NIST and others also use the term because it's well-established in PKI. I'm reading it in a number of places in the NIST 800-130 spec for cryptographic key frameworks. The fact that different protocols work in different ways is a function of the protocol, not the name of the entity performing a role in the protocol. For example, many protocols use the term "Subject" to refer to the main actor in the protocol. They don't create a new term for this role just because it's a different protocol. Thus to use a different term that the rest of the industry for the role that everyone in the industry recognizes seems like it is just going to cause confusion and increase the adoption hurdle. All of which could be avoided by one paragraph in the spec that explains exactly what you did above, i.e., "How a Verifiable Claims Relying Party is different than an OpenID Relying Party or a ______________ Relying Party". |
|
I like relying party, mostly because it is clearly the third part of the triangle in the rest of the IdM conversations I know of. It easily maps to a well-understood referent for many. However, that's tempered by two things. First, I would prefer a single word term rather than a multi-word phrase. There are times when you need to say things like "subject/holder/relying-party" and it's awkward. I'm not even sure that the right way to do it. It almost certainly isn't "subject/holder/relying party", but apparently the Chicago and AP style guides disagree, both with each other and with my approach. Second, it leans towards "identity" rather strongly. I'm a fan of identity, but I think for alignment with the rest of the W3C we would do well to avoid sounding like an identity solution. That said, it should definitely be an option in the poll. |
|
Joe, just a brief note that "relying party" has been used in PKI long before its usage with identity protocols. |
|
@talltree wrote:
@jandrieu wrote:
@ChristopherA wrote:
There are enough proponents of "Relying Party" now that it should be a poll option. I'm adding the option now. |
|
Data Model Ideas An Issuer issue claims about Subjects using Identifiers |
|
I just want to support two points made by Dave Longley in today's call. First, "folks are sometimes favoring a term for their most cherished use cases, but we haven't really spent the time to distill the most common denominator." That's understandable, but what we need is the essential roles, the roles that always do what they do--even if they are done by the same party or by parties better known by a different name. A well named role will still do what is expected in every use case. Second, the main strength or feature of Verifiable Claims is that party A can make a claim that party B can share with party C, where: party C doesn't have to trust party B and party A doesn't have to know that party B shared the claim with party C. Let me break out the part that jumped out at me: party C doesn't have to trust party BThis is the essence of my argument that Party B (Role_C elsewhere) should not be defined based on its entitlement to present the claim. Because we have no means to verify that entitlement within the Verifiable Claims infrastructure. The entire VC architecture is based on not needing to trust the holder/presenter/claimant. Yes, there are use cases where the VCs usefulness will depend on the ability of the Inspector/Relying Party/Verifier being able to deduce some facts about the presenter--because there are assertions being made outside the claim about the relationship of the presenter to the subject. BUT THAT IS NOT ESSENTIAL to all use cases. Further, it obfuscates the unique value of Verifiable Claims. While one could use VCs to bootstrap facts about the presenter (by establishing that the presenter is the subject or delegate for one or more claims), the knotty problem we are fundamentally sidestepping is the presenter who misrepresents the facts. Or in reverse, the power of VCs is in the verifiability of the statement in the claim in the face of an untrustworthy presenter. Even if they have spoofed whatever entitlement check as presenter, the claim itself stands on its own thanks to both cryptographic trust and procedural revocability. As such, I think its is a fundamental error to define the presenter/holder/claimant as "entitled to represent the Subject of the Claims." or saying that they "must be able to prove that he/she is authorized to provide the Claims." The only role that is always true for the presenter/holder/claimant is that they are the one presenting the claim/profile with the inspector (sharing, presenting, etc.). |
|
I agree. I was in favour of RP many months ago when we have a previous
poll on terms
David
…On 27/06/2017 03:05, Drummond Reed wrote:
Manu, while I get all that, ironically your answer almost seems to prove
my point. Literally everyone is using the term "relying party" for "the
third point on the triangle", i.e., the party that relies on the the
results of the protocol—in this case the delivery of a verifiable claim.
The fact that different protocols work in different ways is a function
of the protocol, not the name of the entity performing a role in the
protocol. Thus to use a different term that the rest of the industry for
the role that everyone in the industry recognizes seems like it is just
going to cause confusion and increase the adoption hurdle, all of which
could be avoided by one paragraph in the spec that explains exactly what
you did above, i.e., "How a Verifiable Claims Relying Party is different
than an OpenID Relying Party or a ______________ Relying Party".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#56 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADe4_8V8RrjyXzo5j9XGANHHvzKNXWUIks5sIGNwgaJpZM4N1-3v>.
|
|
I made some comments on the mailing list regarding how I think the remaining roles to be named ought to be defined: https://lists.w3.org/Archives/Public/public-credentials/2017Jun/0166.html |
|
Needless to say I disagree with you.
My driving license is a verifiable document that stands in its own
right, so it fulfils your definition of a VC (though I re-iterate that
it is not a claim. The authority that issued it is not making any claim.
They are stating a fact that David Chadwick is entitled to drive certain
classes of motor vehicle in their jurisdiction. So we should dump the
use of the term claim to refer to the verifiable credentials).
If you present my driving license to a police officer who stops you when
driving a car, then this also fulfils your statement "the power of VCs
is in the *verifiability of the statement in the claim in the face of an
untrustworthy presenter*".
The police officer certainly does not trust you, so this fulfils the
trust rule as well.
You are the untrustworthy presenter who presents a verifiable credential.
Where does that leave us without any additional functionality? It means
that VCs are totally useless for most (all?) practical purposes.
This is why my assertion that the statement "must be able to prove that
he/she is authorized to provide the Claims" is a fundamental feature of
VCs. It is used to address "the knotty problem .... is the presenter who
misrepresents the facts". So we are not side-stepping this problem as
you assert. We are addressing it head on with the requirement to prove
that you are authorised to make the claim.
I would be pleased for you to give me a VC use case where this
requirement is not needed. (And please do not give me a use case where
the VC is a statement of public information that everyone is entitled to
present).
Regards
David
…On 27/06/2017 17:33, Joe Andrieu wrote:
I just want to support two points made by Dave Longley in today's call.
First, "folks are sometimes favoring a term for their most cherished use
cases, but we haven't really spent the time to distill the most common
denominator." That's understandable, but what we need is the essential
roles, the roles that always do what they do--even if they are done by
the same party or by parties better known by a different name. A well
named role will still do what is expected in every use case.
Second, the main strength or feature of Verifiable Claims is that party
A can make a claim that party B can share with party C, where: party C
doesn't have to trust party B and party A doesn't have to know that
party B shared the claim with party C.
Let me break out the part that jumped out at me:
*party C doesn't have to trust party B*
This is the essence of my argument that Party C should not be defined
based on its entitlement to present the claim. Because we have no means
to verify that entitlement within the Verifiable Claims infrastructure.
The entire VC architecture is based on not needing to trust the
holder/presenter/claimant.
Yes, there are use cases where the VCs usefulness will depend on the
ability of the Inspector/Relying Party/Verifier being able to deduce
some facts about the presenter--because there are assertions being made
outside the claim about the relationship of the presenter to the
subject. BUT THAT IS NOT ESSENTIAL to all use cases. Further, it
obfuscates the unique value of Verifiable Claims.
While one could use VCs to bootstrap facts about the presenter (by
establishing that the presenter is the subject or delegate for one or
more claims), the knotty problem we are fundamentally sidestepping is
the presenter who misrepresents the facts.
Or in reverse, the power of VCs is in the *verifiability of the
statement in the claim in the face of an untrustworthy presenter*. Even
if they have spoofed whatever entitlement check as presenter, the claim
itself stands on its own thanks to both cryptographic trust and
procedural revocability.
As such, I think its is a fundamental error to define the
presenter/holder/claimant as "entitled to represent the Subject of the
Claims." or saying that they "must be able to prove that he/she is
authorized to provide the Claims."
The only role that is always true for the presenter/holder/claimant is
that they are the one presenting the claim/profile with the inspector
(sharing, presenting, etc.).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#56 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADe4_9yH5BVqJsgvIP6QikTU7pWJb7fIks5sIS7JgaJpZM4N1-3v>.
|
|
On Wed, Jun 28, 2017, at 05:58 AM, David Chadwick wrote:
Needless to say I disagree with you.
My driving license is a verifiable document that stands in its own
right, so it fulfils your definition of a VC (though I re-
iterate that> it is not a claim. The authority that issued it is not making
any claim.> They are stating a fact that David Chadwick is entitled to drive
certain> classes of motor vehicle in their jurisdiction. So we should dump the> use of the term claim to refer to the verifiable credentials).
They certainly are making claims regarding the privilege of driving,
height, weight, address. As we've defined it, a claim is a statement. It
makes it challenging to have a productive conversation if you aren't
willing to establish terminology and move on to the next issue.
If you present my driving license to a police officer who stops
you when> driving a car, then this also fulfils your statement "the
power of VCs> is in the *verifiability of the statement in the claim in the
face of an> untrustworthy presenter*".
The police officer certainly does not trust you, so this fulfils the> trust rule as well.
You are the untrustworthy presenter who presents a verifiable
credential.>
Where does that leave us without any additional functionality?
It means> that VCs are totally useless for most (all?) practical purposes.
It means the assertion that the presenter is the subject of the
credential is fundamentally outside the claim. As in your example, the
driver's license doesn't say ANYTHING about the person driving the car.
It says what it says about the subject. It also provides additional
biometric data in the form of a photo, height, weight, etc. so that
anyone relying on the credential can *further* correlate the subject of
the claim with the presenter. That assurance process is performed by the
relying party; both the quality of assurance and mechanisms for doing so
are external to the credential.
Nowhere in the VC architecture do we provide hooks for this external
identity assurance.
This is why my assertion that the statement "must be able to
prove that> he/she is authorized to provide the Claims" is a fundamental
feature of> VCs. It is used to address "the knotty problem .... is the
presenter who> misrepresents the facts". So we are not side-stepping this problem as> you assert. We are addressing it head on with the requirement
to prove> that you are authorised to make the claim.
I think you misunderstand what we are doing here. There is nothing in
the data model that provides for identity assurance.
Even in the case of KYC, the initial bootstrapping of an identity is the
identity assurance. Having proven once that I am a particular individual
with particular identifiers that represent me as a subject, then I can
present all sorts of claims with me as a subject that are now reasonably
acceptable to the relying party.
Yes, these sorts of well-known identifiers are potential privacy
problems. Nevertheless, the mapping of current authorities and
credentials to verifiable claims will transform several core
transactions currently dependent on either centralized or paper
credentials.
I would be pleased for you to give me a VC use case where this
requirement is not needed. (And please do not give me a use
case where> the VC is a statement of public information that everyone is
entitled to> present).
You just named a whole category of use cases. Just because everyone is
entitled to present it doesn't make it an invalid VC use case.
I've mentioned others, such as the educational credential posted in a
closed but connected social network where anyone with member access to
the resource has the functional ability to download the credential and
forward it to a colleague. The mere ability to do the thing is more
relevant to the architecture than the "right" or "proof of privilege" to
do it. Nowhere do we have even the hint of that capability.
VCs are not about identity assurance and the recent approval process of
the working group made that even clearer.
If we were to be in the business of identity assurance, we would have a
HUGE amount of work ahead of us that has never even been discussed, like
how you distinguish between the person currently using the device and
the person usually using the device. The physical person sitting in the
chair may or may not be the person represented in the claims stored on
that machine. Or situations where authentication credentials are shared
among individuals with close relations, even though the service provider
considers the account to be for a single individual. Or even the
situation where someone's private keys are stolen. Proof of control is
only one aspect of the overall problem of identity assurance.
Identity assurance is an extremely non-trivial problem and we have not
even begun to discuss it, much less find a consensus around a reasonable
approach to doing it.
Instead, what we do have consensus around is an approach to reliably
allow an untrusted second party to deliver to a third party a profile
comprised of various claims from one or more authorities (the first
party), where the
1. entire system is open to anyone to create, present, or verify claims2. the issuer and the verifier need not communicate,
a. avoiding the privacy leak of the issuer/authority knowing about
every presentations of every claim b. avoiding the need for the issuer to maintain a reliable 24/7
service endpoint
This is value enough without imagining that we are *also* going to
somehow solve the complex problem of identity assurance.
-j
… On 27/06/2017 17:33, Joe Andrieu wrote:
> I just want to support two points made by Dave Longley in today's
> call.> >
> First, "folks are sometimes favoring a term for their most
> cherished use> > cases, but we haven't really spent the time to distill the most
> common> > denominator." That's understandable, but what we need is the
> essential> > roles, the roles that always do what they do--even if they are
> done by> > the same party or by parties better known by a different name.
> A well> > named role will still do what is expected in every use case.
>
> Second, the main strength or feature of Verifiable Claims is that
> party> > A can make a claim that party B can share with party C, where:
> party C> > doesn't have to trust party B and party A doesn't have to know that> > party B shared the claim with party C.
>
> Let me break out the part that jumped out at me:
>
>
> *party C doesn't have to trust party B*
>
> This is the essence of my argument that Party C should not be
> defined> > based on its entitlement to present the claim. Because we have no
> means> > to verify that entitlement within the Verifiable Claims
> infrastructure.> >
> The entire VC architecture is based on not needing to trust the
> holder/presenter/claimant.
>
> Yes, there are use cases where the VCs usefulness will depend
> on the> > ability of the Inspector/Relying Party/Verifier being able to
> deduce> > some facts about the presenter--because there are assertions
> being made> > outside the claim about the relationship of the presenter to the
> subject. BUT THAT IS NOT ESSENTIAL to all use cases. Further, it
> obfuscates the unique value of Verifiable Claims.
>
> While one could use VCs to bootstrap facts about the presenter (by> > establishing that the presenter is the subject or delegate for
> one or> > more claims), the knotty problem we are fundamentally
> sidestepping is> > the presenter who misrepresents the facts.
>
> Or in reverse, the power of VCs is in the *verifiability of the
> statement in the claim in the face of an untrustworthy
> presenter*. Even> > if they have spoofed whatever entitlement check as presenter, the
> claim> > itself stands on its own thanks to both cryptographic trust and
> procedural revocability.
>
> As such, I think its is a fundamental error to define the
> presenter/holder/claimant as "entitled to represent the Subject
> of the> > Claims." or saying that they "must be able to prove that he/she is> > authorized to provide the Claims."
>
> The only role that is always true for the
> presenter/holder/claimant is> > that they are the one presenting the claim/profile with the
> inspector> > (sharing, presenting, etc.).
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#56 (comment)>
> ,> > or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ADe4_9yH5BVqJsgvIP6QikTU7pWJb7fIks5sIS7JgaJpZM4N1-3v>
> .> >
— You are receiving this because you were mentioned. Reply to this
email directly, view it on GitHub[1], or mute the thread[2].>
--
Joe Andrieu, PMP
[email protected]
+1(805)705-8651
http://blog.joeandrieu.com
Links:
1. #56 (comment)
2. https://github.com/notifications/unsubscribe-auth/AALZzx005U4sveF3H1r4JVgOKoVK9D59ks5sIiPXgaJpZM4N1-3v
|
This is a moderate rework of the introductory text and images for the specification for the purposes of making the introductory section of the FPWD easier to read for newcomers.