Re: [SPICE] Informal Meeting Notes (errata)

[Orie Steele <[e-mail]>]

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>