Re: [saag] Call for consensus on SPICE charter

[Ira McDonald <[e-mail]>]

Hi Denis,

Thanks.  I stand corrected.

I still suggest that SPICE folks inform themselves about IETF RATS WG
activities and documents,
including of course EAT (Entity Attestation Token) in the RFC Editor queue
since December 2023.
https://datatracker.ietf.org/doc/draft-ietf-rats-eat/

RATS operations, terminology, and architecture are already in use in IETF
SUIT WG (S/W Update),
IETF TEEP WG (TEE Provisioning, spanning several CPU architectures), and
others, for claims
that include identity and evidence about validity.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*


On Fri, Feb 23, 2024 at 9:31 AM Denis <[e-mail]> wrote:

> Hi Ira,
>
> FYI, the word "Verifier" as used in RFC 9334 does not map to the
> "Verifier" role as currently used in the three roles model:
> i.e., Holder, Issuer and Verifier, e.g., in VCDM 2.0 from W3C.
>
> You wrote:
>
> "A Verifier who never verifies anything is not a useful term".
>
> A verifier never verifies, nor validates, digital *credentials*, since it
> only verifies digital *presentations*.
>
> Please read again the following sentence:
>
> A "verifier", an application running in a trusted environment that *verifies
> digital presentations* received from a holder.
>
> This sentence does use the verb "verify".
> Denis
>
> Hi Denis,
>
> Conflating verification with validation is not helpful.  A Verifier who
> never verifies anything is not
> a useful term.
>
> It would be appropriate, given the five years of prior work quite close to
> the apparent topic of
> SPICE, if people read and thought about the terminology already widely
> used in IETF working
>  drafts from RATS Architecture (RFC 9334).
>
> Cheers,
> - Ira
>
>
> On Fri, Feb 23, 2024 at 6:37 AM Denis <[e-mail]> wrote:
>
>> Margaret,
>>
>> I have the same problem as yourself, .... and many more. See my email
>> from yesterday.
>> https://mailarchive.ietf.org/arch/msg/spice/eRxcl2xXJEgIYiKWPATZKPuBVcI/
>>
>> I wrote:
>>
>> Furthermore, there is a confusion in the proposed text between "digital
>> credentials" and "digital presentations".
>>
>> Replace by:
>>
>> An "issuer", an application running in a trusted environment that issues
>> digital credentials to its *subscribers **and takes care of their
>> validity statu*s.
>>
>> A "holder", an application running in a trusted environment under the
>> control of a user that requests digital credentials to one or more issuers,
>> store them and builds from them digital presentations that are then
>> communicated to a verifier.
>>
>> A "verifier", an application running in a trusted environment that
>> verifies digital presentations received from a holder.
>>
>> When the digital credential issuer sends back to the holder a digital
>> credential (after a digital credential request),
>> the holder needs to verify that the digital credential it receives
>> matches with its request.
>>
>> A verifier never verifies, nor validates, digital credentials.
>>
>> A verifier receives a digital *presentation* (derived from a digital
>> credential) that he needs to validate.
>>
>> There is no need to introduce a "validator".
>>
>>
>> IMO, in order to be approved, the charter will need to be corrected in
>> several places.
>>
>>
>> Denis
>>
>> I strongly support the creation of this WG, and my answers to the formal
>> consensus questions are listed below.
>>
>> However, I do have one comment on the charter text….
>>
>> > A "verifier", an entity (person, device, organization,
>> > or software agent) that verifies and validates secured
>> > digital credentials.
>>
>> I question the assumption that the credential will be verified and
>> validated by the same entity.  I would prefer to see these broken out into
>> separate roles.  I think that in some cases a credential may be issued and
>> verified by the same entity and verified by another entity. Or in some
>> cases, all three roles could be separate.
>>
>> For instance, a student at a university could present a digital
>> University ID.  The credential could be issued by, and perhaps even
>> verified by, the university.  However, if the holder needed to validate
>> that the issuer was a properly-accredited, US university, a third-party
>> validation could be needed to confirm that fact.
>>
>> So, I would prefer to see the verifier and the validator listed as
>> separate roles.
>>
>> However, this is a comment on the text, not an objection to WG formation.
>>
>> Margaret
>>
>>
>> (1) Do you support the charter text? Or do you have objections or
>> blocking concerns (please describe what they might be and how you would
>> propose addressing the concern)?
>>
>> mrc> Yes, with one comment, above.
>>
>> If you do support the charter text:
>> (2) Are you willing to author or participate in the developed of the WG
>> drafts?
>>
>> mrc> Yes
>>
>> (3) Are you willing to review the WG drafts?
>>
>> mrc> Yes
>>
>> (4) Are you interested in implementing the WG drafts?
>>
>> mrc> interested? Yes!  But as consultants and operators, we’d be more
>> likely to deploy and operate an open source implementation of this
>> technology for someone else, which we would be eager to do.
>>
>> _______________________________________________
>> saag mailing [e-mail]://www.ietf.org/mailman/listinfo/saag
>>
>>
>> _______________________________________________
>> saag mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/saag
>>
>
>