Re: [saag] Call for consensus on SPICE charter

[Denis <[e-mail]>]

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 <[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 list
>>>         [e-mail]
>>>         https://www.ietf.org/mailman/listinfo/saag
>>
>>
>>         _______________________________________________
>>         saag mailing list
>>         [e-mail]
>>         https://www.ietf.org/mailman/listinfo/saag
>>
>