Re: Identifiers in Verifiable Credentials

I'm fine with the semantics i.e. positive/negative claims being out of
scope, but the standard does still, of course, describe a VC being issued.
If an issuer can issue a claim for any reason, then it follows that it
should be able to revoke a claim for any reason.

So we could say something like "A VC may also be revoked by an issuer in
any circumstance, for example where the issuer decides it should not have
issued the credential in the first place, or it no longer itself believes
the claims made by the assertion to the same degree of confidence as
before."

I feel like this would be a helpful clarification, rather than leaving
people to perhaps guess that they must come up with other mechanisms for
revocation :-)

George


On Mon, 7 Jun 2021 at 23:59, David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

> Hi Steve
>
> you already spotted the answer
> On 07/06/2021 23:41, Steve Capell wrote:
>
> You are welcome ;)
>
> But I did read it carefully (pasted text below) and I still disagree.  The
> reason goes back to the same discussion I constantly seem have on this
> thread.  That the group thinks almost exclusively about VCs about people.
> Whilst I think almost exclusively about VCs about things - and occasionally
> about businesses.
>
> Permits, licences, certificates issued about businesses or consignments  -
> almost always can (and must) be revocable - in a business sense, not just a
> technical / PKI sense.  Leaving that to the vagaries of different semantics
> seems to impose a big interoperability risk.
>
> Then again, I suppose there’s nothing to stop an issuer revoking a
> credential using the “technical protocol” even if the cause is that a non
> compliance demands that the export permit be revoked….?
>
> Correct. The issuer is revoking the VC therefore the verifier should no
> longer rely on it. Whether the issuer revoked it for a technical reasons or
> a semantic reasons is not visible in the act of revocation, since no
> revocation reasons are standardised (unlike for example X.509 which has
> standardised reasons). Thus it is actually a moot point as to why the VC
> was revoked. The W3C spec has to say it is due to the VC no longer being
> technically valid, because it already says that the truth of an assertion
> is out of scope of the standard. So it cannot then say that a VC was
> revoked because the assertion was no longer true, since this is out of
> scope.
>
> Kind regards
>
> David
>
>
>
>
> Your text :
>
> “ There are two aspects of revocation that are potentially of concern to
> VC stakeholders, in particular, to verifiers. The first is that which is
> typically referred to as revocation in the PKI world, and this means that
> the VC should not be trusted because either the cryptography is broken, or
> the private key of the issuer or subject has been stolen etc. In this first
> case, the underlying identity information is still valid e.g. the subject
> is still a citizen of the country, is still a member of the club etc. but
> the VC cannot be relied upon to verify this. For example, a thief might be
> able to use a cryptographically broken VC to masquerade as the subject,
> hence it needs to be revoked. *The second aspect is that the underlying
> assertion is no longer valid e.g. the subject is dead or is no longer a
> member of the club etc.* Since the VC working group is not interpreting
> the semantics of the VC attributes, then this latter aspect is out of scope
> of the working group (in just the same way that negative VCs are out of
> scope). Consequently we will only concentrate on revoking VCs as part of
> their life cycle, when the cryptography cannot be relied upon to verify the
> VC.”
>
> Steven Capell
> Mob: 0410 437854
>
> On 8 Jun 2021, at 12:48 am, David Chadwick
> <d.w.chadwick@verifiablecredentials.info>
> <d.w.chadwick@verifiablecredentials.info> wrote:
>
> 
>
>
> On 07/06/2021 14:02, Steve Capell wrote:
>
> Ok thanks David
>
> By the way, I found this to be very helpful
> https://w3c-ccg.github.io/vc-lifecycle/
>
> Thanks, I wrote most of this.
>
>
>
> Although I’d question the last part of section 9 where the authors assert
> (correctly) that credential semantics are out of scope but then say
> revocation is semantics so out of scope
>
> Not quite. It is saying that the second aspect is out of scope, since VCs
> say nothing about the truth of the assertions that they contain. Thus they
> cannot revoke semantically something that they dont know is true and say it
> is false.
>
>
>
> The ability to revoke a credential seems like such a ubiquitous need that
> it seems to me that it’s appropriate to put in the protocol / standard
> lifecycle layer and not leave it only in the semantic content.
>
> It supports this in the first aspect. Have a close read again
>
> Kind regards
>
> David
>
>
>
> Steven Capell
> Mob: 0410 437854
>
> On 7 Jun 2021, at 9:58 pm, David Chadwick
> <d.w.chadwick@verifiablecredentials.info>
> <d.w.chadwick@verifiablecredentials.info> wrote:
>
> 
>
> There is delegation of authority in this case. ACME delegates to its
> customer and the customer is delegating to its chosen importer. So the
> verifier is able to verify a chain of trust if this is desired. But if you
> don't want to go to this level of protection then ACME can make its VCs
> bearer credentials (so anyone who possesses them is authorised to present
> them) and the subject properties would contain a description of the subject
> object along with their properties.
>
> Kind regards
>
> David
> On 07/06/2021 11:10, Steve Capell wrote:
>
> >> ACME provides that VC
>
> The ultimate verifier is the importing customs authority. the presenter is
> the customs broker selected by the importer (who is ACMEs customer).
>
> In this scenario the subject (ACME) has no relationship with the final
> holder/presenter (customs broker) and verifier (importing authority) so
> can’t possibly provide any delegated authority.   ACME is basically saying
> (to its customer the importer), “here is proof that I’m an Australian
> trusted trader - do whatever you want with it”
>
> I suppose acme is delegating a “show this to whoever you want” authority
> to the importer
>
> Steven Capell
> Mob: 0410 437854
>
> On 7 Jun 2021, at 7:59 pm, David Chadwick
> <d.w.chadwick@verifiablecredentials.info>
> <d.w.chadwick@verifiablecredentials.info> wrote:
>
> 
>
> Hi Steve
> On 07/06/2021 10:24, Steve Capell wrote:
>
> Sorry - in the middle case I meant to say the “subject is not the
> presenter” not “the holder is not the presenter “
>
> I think the general state will be that there is a linked data graph of
> verifiable claims.  The verifier follows the thread like pulling on the end
> of a piece of string and finding forks and joins and little gems as they
> pull.
>
> Maybe there’s even a VC about a whole graph so that verifiers don’t need
> to pull the string..
>
> Steven Capell
> Mob: 0410 437854
>
> On 7 Jun 2021, at 7:15 pm, Steve Capell <steve.capell@gmail.com>
> <steve.capell@gmail.com> wrote:
>
>  What about the case where there is a subject but the VC is also
> presented by a bearer
>
> The bearer is the holder. Always.
>
>
>
> For example
>
> Issuer (border agency) issues a VC about a subject (ACME) that asserts
> that ACME is an Australian Trusted Trader.
>
> I have a similar use case to this.
>
>
>
> ACME provides that VC
>
> It is not ACME that provides it, but an authorised official of ACME that
> provides it. This official will have his/her own key pair (Unless ACME has
> its own key pair and the private key is given to authorised officials by
> some internal company procedure). Which model are you suggesting?
>
>
> (together with several others like an IP rights ownership VC (about a
> product ) and a certificate of origin VC (about a consignment) with their
> export document bundle to their customer (importer) who gives some of them
> to a customs broker who passes them to the importing border authority
> (customs) who is the verifier of the trusted trader VC and the origin VC
> (but doesn’t care about the IP rights vc). The IP rights VC is a direct
> exporter (ACME) holder to verifier (importer) VC.
>
> This is pretty much business as usual in international trade - which
> comprises maybe 10 billion consignments (and hence VC bundles) per year
>
> We have a combination of
> - pure bearer VCs (eg the origin certificate where the subject is a
> consignment of goods)
>
> A bearer VC has no subject ID. So if the subject is the goods then it is
> not a bearer VC. The VC will be held by someone other than the subject
> (unless the goods has its own digital twin which can be the holder and the
> subject).
>
>
> - traditional holder VCs (eg the trusted trader status) - except that the
> holder is not the presenter so it’s kind of a holder VC used like a bearer
> VC
>
> This is the case where the subject NE holder. In this situation the holder
> has to prove to the verifier that it is entitled to present the VC on
> behalf of the subject. There are a multitude of ways of doing this.
>
>
> - pure holder is presenter (the scenario most often discussed in this
> group but the least common in cross border trade)
>
> The holder is ALWAYS the presenter. This is the model. There are only
> subjects and holders. No other roles
>
>
>
> Whet is the correct use of subject ID and VC assertion ID in each of these
> cases?
>
> The subject ID always refers to the subject of the VC about which the
> assertions are made. What do you mean by assertion ID? VC ID?
>
> Kind regards
>
> David
>
>
>
> Steven Capell
> Mob: 0410 437854
>
> On 7 Jun 2021, at 6:52 pm, David Chadwick
> <d.w.chadwick@verifiablecredentials.info>
> <d.w.chadwick@verifiablecredentials.info> wrote:
>
> 
>
>
> On 06/06/2021 22:57, Kerri Lemoie wrote:
>
> Hello all,
>
> I have a question about identifiers in verifiable credentials. The documentation states:
>
> "When expressing statements about a specific thing, such as a person, product, or organization, it is often useful to use some kind of identifier so that others can express statements about the same thing. This specification defines the optional id property for such identifiers. The id property is intended to unambiguously refer to an object, such as a person, product, or organization. Using the id property allows for the expression of statements about specific things in the verifiable credential."
>
>
> In the credentialSubject property it seems clear that the id can represent the subject that the claim is about but I’m not clear on the uses for the optional id in the vc assertion. It would be helpful to learn about some examples or suggested uses.
>
> The id is optional for the case where the VC is a bearer VC e.g. a ticket
> to an event. This means that the properties are not bound to a subject, but
> can be presented by anyone who possesses the VC.
>
> Kind regards
>
> David
>
>
> For some context: in VC-EDU, we’re discussing Open Badges as VCs. Open Badges have historically mostly been verified via issuer hosted URLs.  One of the reasons to move away from hosted URLs is to remove the dependence on the issuer for verification. However, there may continue to be use cases for when an Open Badge should still be verified through its hosted url.
>
>
> Thanks,
>
> Kerri
>
>
>
>

-- 
George Lund
Technical Architect
Digital Identity Programme
Government Digital Service