Re: [SPICE] Informal Meeting Notes (errata)

[Denis <[e-mail]>]

Orie,

The right wording would then be : "Data and metadata discovery", since 
metadata alone without data does not make sense.
In the example you provide, we have XXXX Metadata, i.e, JWT Issuer Metadata.

Secondly, what about the removal of the word "issuers" ?

Denis


> I fall in line with Orie on this one.  I think use of the term 
> metadata is helpful here and aligns with other uses of the term 
> elsewhere im ietf docs
>
> Mike Prorock
> CTO - mesur.io <http://mesur.io>
>
> On Fri, Jan 5, 2024, 07:03 Orie Steele <[e-mail]> wrote:
>
>     Issuer metadata discovery is key to understanding "what kind of
>     credentials can I get" and "what formats are coming in" and "how
>     can I get them".
>
>     The word metadata is a generic term to describe data...
>     about data... In this case that solves the problem of "what
>     (meta)data is discoverable about issuers, holders and verifiers".
>
>     And all the examples we provide such as keys, claims,
>     credentials and proofs, are examples of data which we might want
>     to retrieve additional information (metadata) regarding.
>
>     Our use of the word, is consistent with other IETF working groups,
>     for example:
>
>     https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-01#name-jwt-issuer-metadata
>
>     I don't agree with your proposal.
>
>     OS
>
>     On Fri, Jan 5, 2024 at 1:53 AM Denis <[e-mail]> wrote:
>
>         Hi Orie and all,
>
>>         I rephrased your suggestion here:
>>
>>         https://github.com/transmute-industries/ietf-spice-charter/commit/3848dac6c5b7b2ab5d91c0bb909c3f959eb2b197
>>
>         The new sentence is :
>
>             A meta-data discovery document enabling issuers, holders
>             and verifiers to discover supported protocols and formats
>             for keys, claims, credentials and proofs.
>
>         I would propose to drop the words "meta-data" and "issuers,".
>         As mentioned earlier, an issuer does not need to discover
>         anything.
>
>             A  discovery document enabling holders and verifiers to
>             discover supported protocols and formats for keys, claims,
>             credentials and proofs.
>
>         Denis
>
>>         I don't know what a "credential request format" is but I
>>         assume it's some protocol (possibly one of many) for
>>         issuance (delivering a credential from an issuer to a holder).
>>
>>         You also did not include "presentation request format", which
>>         would be some protocol (possibly one of many) for delivering
>>         a proof (or presentation) from a holder to a verifier.
>>
>>         I used "supported protocols and formats" to capture these
>>         requirements.
>>
>>         You might consider data URIs presented through animated QR
>>         Codes to be an example of part of a presentation protocol.
>>
>>         I suspect that commenting on "supported protocols"
>>         might raise the question of if SPICE will define issuance or
>>         presentation protocols.
>>
>>         I think it's ok to keep it as is and not define any protocols
>>         under the first charter, even if we enable discovery of
>>         OIDC4VC, OIDC4VP, mDoc Request API, etc...
>>
>>         If you think that we MUST define protocols for issuance and
>>         presentation under the first charter, we will need to add
>>         more milestones, but I don't want to do that.
>>
>>         OS
>>
>>
>>         On Thu, Jan 4, 2024 at 4:24 PM Denis <[e-mail]> wrote:
>>
>>             Error:
>>
>>             Instead of "Verifiable Credential formats", please read:
>>             "Verifiable Presentation formats"
>>
>>             Denis
>>
>>>             Hi Orie,
>>>
>>>             The second document is defined as follows:
>>>
>>>                 A meta-data discovery document focusing on the
>>>                 scalable, Internet-wide discovery of keys,
>>>                 credential formats and meta-data for issuers,
>>>                 holders and verifiers.
>>>
>>>             During the meeting, I was looking for a wording better
>>>             than "key discovery" or "meta-data discovery"and I could
>>>             not find it.
>>>             After the meeting, I believe that "formats discovery"
>>>             would be more appropriate.
>>>             In the list, "credential request formats", "proof
>>>             formats" (i.e.; Verifiable Credential formats - using
>>>             the W3C vocabulary) are "claims formats" are missing.
>>>
>>>             Below is my proposal:
>>>
>>>                 A "formats discovery" document focusing on the
>>>                 scalable, Internet-wide discovery of credential
>>>                 formats, *
>>>                 credential request formats, proof formats*, *claims
>>>                 formats* and keys for holders and verifiers.
>>>
>>>             I dropped "issuers" from the list, since an issuer does
>>>             not need to "discover" anything.
>>>
>>>             Denis
>>>
>>>>             Hello Spice Enthusiasts,
>>>>
>>>>             Call attendance:
>>>>
>>>>             - Orie Steele
>>>>             - Alexander Stein
>>>>             - Brent Zundel
>>>>             - Denis
>>>>             - Henk Birkholtz
>>>>             - Heather Flanagan
>>>>             - Justin Richer
>>>>             - Pam Dingle
>>>>             - Rifaat Shekh-Yusef
>>>>
>>>>             Call agenda:
>>>>
>>>>             - Charter Text Revisions
>>>>             -
>>>>             https://github.com/transmute-industries/ietf-spice-charter/pull/17
>>>>
>>>>             Minute Summary:
>>>>
>>>>             We discussed recent feedback on the MLS charter, and
>>>>             decided to remove the "history section" except for the
>>>>             3rd paragraph, which was proposed by @Hannes Tschofenig
>>>>             <mailto:[e-mail]> .
>>>>
>>>>             We discussed the "Key Discovery" milestone deliverable,
>>>>             and revised it to be "meta data discovery" and include,
>>>>             keys, issuer, holder, verifier metadata including
>>>>             supported "formats".
>>>>
>>>>             We discussed the possibility of including an
>>>>             informative use cases document. There was rough
>>>>             consensus to omit this document from the official
>>>>             milestones, but comments that it still might be useful
>>>>             as the group developed the architecture, and a
>>>>             suggestion to perhaps put it on the wiki when we have one.
>>>>
>>>>             We had unanimous agreement that the 3 proposed
>>>>             milestones are the right starting point for the charter.
>>>>
>>>>             We had no additional milestones or recommendations
>>>>             proposed.
>>>>
>>>>             There remains some concern the initial charter text is
>>>>             too long, see the latest text here:
>>>>
>>>>             https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md
>>>>
>>>>             The call time remains the same until we announce
>>>>             otherwise, everyone is welcome to attend (we are not a
>>>>             formal working group yet):
>>>>
>>>>             https://github.com/transmute-industries/ietf-spice-charter?tab=readme-ov-file#meetings
>>>>
>>>>             Regards,
>>>>
>>>>             OS
>>>>
>>>>             -- 
>>>>
>>>>
>>>>             ORIE STEELEChief Technology
>>>>             Officerwww.transmute.industries
>>>>             <http://www.transmute.industries>
>>>>
>>>>             <https://transmute.industries>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>         -- 
>>
>>
>>         ORIE STEELEChief Technology Officerwww.transmute.industries
>>         <http://www.transmute.industries>
>>
>>         <https://transmute.industries>
>>
>
>
>
>     -- 
>
>
>     ORIE STEELEChief Technology Officerwww.transmute.industries
>
>     <https://transmute.industries>
>
>     -- 
>     SPICE mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/spice
>