Re: [SPICE] Informal Meeting Notes (errata)

[Michael Prorock <[e-mail]>]

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

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 <[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 STEELE Chief Technology Officer www.transmute.industries
>>>
>>> <https://transmute.industries>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>>
>>
>> ORIE STEELE Chief Technology Officer www.transmute.industries
>>
>> <https://transmute.industries>
>>
>>
>>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
> --
> SPICE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spice
>