[{"author": "Henk Birkholz", "text": "

If a jwt vc can include remote attestation evidence (e.g., about device authenticity) are they a superset of entity attestation tokens (eat)?

", "time": "2023-07-28T17:06:40Z"}, {"author": "Paul Bastian", "text": "

I would rather say JWT-VC is a possible format for EAT

", "time": "2023-07-28T17:09:02Z"}, {"author": "Torsten Lodderstedt", "text": "

content wise, I would say eats are a possible sub set as sd-jwt vcs can contain all kinds of claims, esp. about human users

", "time": "2023-07-28T17:11:29Z"}, {"author": "Richard Barnes", "text": "

SD-JWT-VC could also be a good substrate for UserInfo VCs https://openid.net/specs/openid-connect-userinfo-vc-1_0.html

", "time": "2023-07-28T17:13:52Z"}, {"author": "Torsten Lodderstedt", "text": "

absolutely!

", "time": "2023-07-28T17:14:16Z"}, {"author": "Benjamin Kaduk", "text": "

I think I missed why explicit typing of JWTs doesn't suffice for the media-type confusion issue

", "time": "2023-07-28T17:20:16Z"}, {"author": "Henk Birkholz", "text": "

Use hands tool?

", "time": "2023-07-28T17:22:10Z"}, {"author": "Ned Smith", "text": "

@Henk Birkholz would you have hummed in the contrary to adoption?

", "time": "2023-07-28T17:26:33Z"}, {"author": "Roman Danyliw", "text": "

We should have asked about remote participants and done an official poll to include the remote participants.

", "time": "2023-07-28T17:27:40Z"}, {"author": "Roman Danyliw", "text": "

This is a process hiccup. If you are remote and would have hummed no, please bring it up

", "time": "2023-07-28T17:28:14Z"}, {"author": "Ned Smith", "text": "

If jwt-vc isn't a profile of W3C VC and isn't compatible with W3C VC. Why call it a VC? Using the same name for different things is confusing.

", "time": "2023-07-28T17:28:33Z"}, {"author": "Henk Birkholz", "text": "

I would have liked a demonstration of knowledge about (the status of) other existing work in the ietf

", "time": "2023-07-28T17:29:23Z"}, {"author": "Ned Smith", "text": "

@Roman Danyliw I would like to understand why the W3C VC chair and others involved with W3C are in favor of adoption.

", "time": "2023-07-28T17:30:21Z"}, {"author": "Henk Birkholz", "text": "

There seem to be a lot redundancies and I hope adopted work takes that into account instead of creating redundant (or slightly out-o-sync) solutions

", "time": "2023-07-28T17:30:43Z"}, {"author": "Roman Danyliw", "text": "

I just spoke with chair. After this presentation, we are going to revisit this topic. Please come to the mic line.

", "time": "2023-07-28T17:31:00Z"}, {"author": "Torsten Lodderstedt", "text": "

@Ned: As co-author of OpenID 4 Verifiable Credentials, a VC is an assertion that is used in the issuer-holder-verifier model. To me, even an ISO mdoc is a VC. the term verifiable credential nowadays stands for a certain kind of assertion. Why using a different name and having to explain to developers they can do the same things (but simpler) as with other VC formats.

", "time": "2023-07-28T17:32:57Z"}, {"author": "Torsten Lodderstedt", "text": "

@Henk: what is redundant?

", "time": "2023-07-28T17:33:35Z"}, {"author": "Ned Smith", "text": "

@Torsten Lodderstedt if the credential isn't verifiable, then is it a \"credential\"?

", "time": "2023-07-28T17:36:14Z"}, {"author": "Torsten Lodderstedt", "text": "

what do you mean?

", "time": "2023-07-28T17:36:40Z"}, {"author": "Kristina Yasuda", "text": "

@Ned Smith term VC is used since that seems to be the most familiar term for the purpose, but it can be revisited in the course of working on this draft.

", "time": "2023-07-28T17:36:43Z"}, {"author": "Kristina Yasuda", "text": "

@Henk Birkholz the use cases slide mentioned SCITT, Richard mentioned MIMI/MLS, this chat mentioned EAT RATS, what else are you looking for?

", "time": "2023-07-28T17:38:04Z"}, {"author": "Ned Smith", "text": "
\n

what do you mean? W3C VC coined the term to mean that a credential should contain metadata that instructs verifiers how to verify the credential. Is that the same goal of JWT-VC?

\n
", "time": "2023-07-28T17:39:24Z"}, {"author": "Torsten Lodderstedt", "text": "

that's how the VC is defined in VCDM 1.1: A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. The claims in a credential can be about different subjects.

", "time": "2023-07-28T17:41:01Z"}, {"author": "Torsten Lodderstedt", "text": "

that's the goal of SD-JWT VCs, too

", "time": "2023-07-28T17:41:45Z"}, {"author": "Darrel Miller", "text": "

Part of the mediaman conversation yesterday was that we need to produce guidance around registering media types that have the same \"base subtype\" but differing suffixes. It would not be a good user experience to have application/vc+foo and application/vc+bar that have significant semantic differences.

", "time": "2023-07-28T17:44:41Z"}, {"author": "Paul Bastian", "text": "

Status list does not include historic data, which is not needed in 99% of use cases. CRL airways grows over time .

", "time": "2023-07-28T17:44:49Z"}, {"author": "Paolo", "text": "

If I have understood correctly SL there might be an issue at privacy levele since the range of possible values is determined by the total size of the SL (as opposed to 2^128 for a random id), every attestation has fewer and fewer number of free indexes that it can be assigned. Is it correct to say that the privacy is continuously decreasing ?

", "time": "2023-07-28T17:46:15Z"}, {"author": "Paul Bastian", "text": "

You can extend existing SL or you can start new SL, so I don't see this point

", "time": "2023-07-28T17:48:58Z"}, {"author": "David Waite", "text": "

Generally we see that it becomes much harder to protect against collusion by the issuer and verifier to determine who the holder is on or after presentation. Privacypass is an example of an architecture for creating solutions there.

", "time": "2023-07-28T17:51:05Z"}, {"author": "David Waite", "text": "

For abuse reporting use cases, such identification may be desirable or even required. The consistent goal is to limit the issuers knowledge of user activity when the holder and verifier are not consciously telling them.

", "time": "2023-07-28T17:52:36Z"}, {"author": "Aaron Parecki", "text": "

I guess you could do the suspension as a 2 bit status, and make the rule that statuses can only go up, so you could go 00=valid, 01=suspended, 10=valid and 11=revoked. So you get one suspension per credential before the credential had to be reissued

", "time": "2023-07-28T17:53:36Z"}, {"author": "Richard Barnes", "text": "

i support the formation of the JKIX working group

", "time": "2023-07-28T17:58:02Z"}, {"author": "Richard Barnes", "text": "

JWKIX

", "time": "2023-07-28T17:58:08Z"}, {"author": "Torsten Lodderstedt", "text": "

the name is to key heavy :rolling_on_the_floor_laughing:

", "time": "2023-07-28T17:58:32Z"}, {"author": "Aaron Parecki", "text": "

needs a catchier acronym

", "time": "2023-07-28T17:58:38Z"}, {"author": "Phillip Hallam-Baker", "text": "

I don't see any value in trying to apply CRLs to this. It is a different encoding, it is a different model, it isn't even a single scheme, it is at least five separate schemes that developed over time.

", "time": "2023-07-28T17:58:40Z"}, {"author": "Ned Smith", "text": "

Some people will want CWKIX too.

", "time": "2023-07-28T17:58:47Z"}, {"author": "Richard Barnes", "text": "

*WKIX

", "time": "2023-07-28T17:59:00Z"}, {"author": "Phillip Hallam-Baker", "text": "

Can take the lessons from the CRL experience. But move on from the realization

", "time": "2023-07-28T17:59:17Z"}, {"author": "Henk Birkholz", "text": "", "time": "2023-07-28T17:59:33Z"}, {"author": "Richard Barnes", "text": "

CWT Revocation Lists (CRLs)

", "time": "2023-07-28T17:59:50Z"}, {"author": "Richard Barnes", "text": "

We have reached the bad-joke stage of the IETF week

", "time": "2023-07-28T18:00:02Z"}, {"author": "David Waite", "text": "

JWX, pronounced \u201cjocks\u201d?

", "time": "2023-07-28T18:00:04Z"}, {"author": "Paul Bastian", "text": "

Status list is a valuable companion to VC specification

", "time": "2023-07-28T18:00:12Z"}, {"author": "Richard Barnes", "text": "

maybe we could run a quick feedback call on SECDISPATCH?

", "time": "2023-07-28T18:03:02Z"}, {"author": "Ned Smith", "text": "

+1 SECDISPATCH

", "time": "2023-07-28T18:03:17Z"}, {"author": "Henk Birkholz", "text": "

never stop working on and progress an I-D whatever its state in the process is.

", "time": "2023-07-28T18:03:20Z"}, {"author": "Aaron Parecki", "text": "

:rocket:

", "time": "2023-07-28T18:06:27Z"}, {"author": "Henk Birkholz", "text": "

most importantly: figure out the claims semantics, eclecticly, and stabilize them sooner than l8r

", "time": "2023-07-28T18:07:05Z"}, {"author": "Roman Danyliw", "text": "

One way to help this conversation might be to explicitly describe the bounds of this collection of related work. This would let us get a sense of whether we all agree on what \"this\" is. This would then help manage the venue exploration and appropriate process discussions.

", "time": "2023-07-28T18:09:43Z"}, {"author": "Michael Jones", "text": "

I agree with John Bradley that since the OAuth WG is the home of JWTs and the draft is a status list for JWTs, adopting this should already be within scope.

", "time": "2023-07-28T18:11:16Z"}, {"author": "Richard Barnes", "text": "

we care about your feelings, Henk

", "time": "2023-07-28T18:11:35Z"}, {"author": "Aaron Parecki", "text": "

That's why I asked about using it with plain JWT access tokens

", "time": "2023-07-28T18:11:49Z"}, {"author": "Torsten Lodderstedt", "text": "

@Roman: sure, can share this on the list.

", "time": "2023-07-28T18:13:12Z"}, {"author": "Roman Danyliw", "text": "

@Torsten: I think that would be a big help

", "time": "2023-07-28T18:13:43Z"}, {"author": "Richard Barnes", "text": "

Proposed: Verifiable Credentials and Related technology (VCR) WG

", "time": "2023-07-28T18:14:05Z"}, {"author": "Aaron Parecki", "text": "

:vhs:

", "time": "2023-07-28T18:14:18Z"}, {"author": "David Waite", "text": "

Sounds like it will do some blockbuster work

", "time": "2023-07-28T18:15:01Z"}, {"author": "Aaron Parecki", "text": "

:drum::boom:

", "time": "2023-07-28T18:15:20Z"}, {"author": "Richard Barnes", "text": "

can't wait until their technology gets to beta

", "time": "2023-07-28T18:15:59Z"}, {"author": "David Waite", "text": "

hold on while I backronym the status list revocation spec to be called REWIND

", "time": "2023-07-28T18:16:29Z"}, {"author": "Torsten Lodderstedt", "text": "

:grinning_face_with_one_large_and_one_small_eye:

", "time": "2023-07-28T18:16:48Z"}, {"author": "Paul Bastian", "text": "

client attstation works both at PAR and token endpoint

", "time": "2023-07-28T18:25:09Z"}, {"author": "Ned Smith", "text": "

Does the OAUTH WG have a vocabulary / arch spec that defines \"attestation\" / \"attestations\"? I didn't find anything in the drafts that have something to do with attestation

", "time": "2023-07-28T18:28:43Z"}]