Re: [SPICE] Informal Meeting Notes (errata)

[Orie Steele <[e-mail]>]

Do you consider "keys" metadata regarding "issuers" or "data" regarding an
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

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
>
> On Fri, Jan 5, 2024, 07:03 Orie Steele <[e-mail]>
> <[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
>>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>