Re: [SPICE] Informal Meeting Notes (errata)

[Denis <[e-mail]>]

Hi Orie,

> Do you consider "keys" metadata regarding "issuers" or "data" 
> regarding an issuers?

I have difficulties to understand your question.

Regarding issuers, *which information do they need to discover* (using a 
discovery protocol ) ? I could not find any.
If you find one,  please give an example. If you found none, then you 
got the rational for the removal of the word "issuers".

> Based on some of your comments, you might be interested in the 
> following references as well:
>
> - 
> https://openid.net/specs/openid-connect-federation-1_0-29.html#name-metadata-type-identifiers
>
I took a look at the document and while reading it the word "object" is 
used many times.

Instead of "data metadata" which sounds odd, I would rather propose 
"Object metadata discovery".

This would lead to :

    An object metadata discovery document enabling holders and verifiers
    to discover supported protocols and formats for keys, claims,
    credentials and proofs.

Denis

> OS
>
>
> On Fri, Jan 5, 2024 at 8:34 AM Denis <[e-mail]> wrote:
>
>     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]> <mailto:[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
>>         <http://www.transmute.industries>
>>
>>         <https://transmute.industries>
>>
>>         -- 
>>         SPICE mailing list
>>         [e-mail]
>>         https://www.ietf.org/mailman/listinfo/spice
>>
>
>
>
> -- 
>
>
> ORIE STEELEChief Technology Officerwww.transmute.industries
>
> <https://transmute.industries>
>