Re: [saag] Call for consensus on SPICE charter

Hi Denis,

Yes I would support the TEEP addition to the charter.

Cheers,
- Ira

On Fri, Feb 23, 2024 at 10:07 AM Denis <denis.ietf@free.fr> wrote:

> Hi Ira,
>
> As a regular participant to the SPICE BoF video conferences each weak, I
> am aware of RATS and of the EAT I-D,
> and so are the other participants.
>
> Henk, the main editor of RFC 9334, is an active participant of the SPICE
> BoF and hence we don't need to "inform ourselves" once more.
>
> The liaison with RATS is currently included in the draft charter, but not
> the liaison with TEEP. Take a look at the following change proposal:
>
> Below the two bullets, there is the following sentence:
>
> The SPICE WG, coordinates with *RATS*, OAuth, JOSE, COSE and SCITT
> working groups that develop documents related to the identity and
> credential space.
>
> The TEEP (Trusted Execution Environment Provisioning) WG has been omitted,
> and should be added since "Trusted Application Managers" are important.
> In particular, the following document should be considered:
> draft-ietf-teep-protocol-17
>
> Change into:
>
> The SPICE WG, coordinates with *RATS, **TEEP*, OAuth, JOSE, COSE and
> SCITT working groups that develop documents related to the identity and
> credential space.
>
> I suppose that you would support this addition.
>
> Denis
>
> 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 <denis.ietf@free.fr> 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 <denis.ietf@free.fr> 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 listsaag@ietf.orghttps://www.ietf.org/mailman/listinfo/saag
>>>
>>>
>>> _______________________________________________
>>> saag mailing list
>>> saag@ietf.org
>>> https://www.ietf.org/mailman/listinfo/saag
>>>
>>
>>
>