[{"author": "Hannes Tschofenig", "text": "

I see a number of remote participants. Thanks for joining!

", "time": "2023-03-28T00:31:33Z"}, {"author": "George Fletcher", "text": "

I'm happy for the more friendly US East coast time slot. Much better than the 2:30am JOSE meeting I joined this morning :)

", "time": "2023-03-28T00:32:47Z"}, {"author": "Hannes Tschofenig", "text": "

As mentioned on the mailing list, we will schedule interim meetings

", "time": "2023-03-28T00:35:22Z"}, {"author": "Anthony Nadalin", "text": "

Thanks for joining us in person Hannes

", "time": "2023-03-28T00:35:56Z"}, {"author": "Hannes Tschofenig", "text": "

\"in person\" via Meetecho

", "time": "2023-03-28T00:38:17Z"}, {"author": "Richard Barnes", "text": "

missed opportunity with the t-shirts, could have been S_-J_T

", "time": "2023-03-28T00:45:47Z"}, {"author": "Hannes Tschofenig", "text": "

+1

", "time": "2023-03-28T00:46:39Z"}, {"author": "Anthony Nadalin", "text": "

Thats not really holder binding, as you don't know how the holder was authenticated or if they were authenticated

", "time": "2023-03-28T00:47:02Z"}, {"author": "Hannes Tschofenig", "text": "

I am also wondering whether the term \"holder binding\" is the right term here.

", "time": "2023-03-28T00:52:29Z"}, {"author": "Anthony Nadalin", "text": "

How do you determine if JSON-LD is used ?

", "time": "2023-03-28T00:52:46Z"}, {"author": "Anthony Nadalin", "text": "

How do you handle the JSON-LD nested structures do they all have to be hashed the same or can they be different disclosure?

", "time": "2023-03-28T00:56:06Z"}, {"author": "Hannes Tschofenig", "text": "

David, did you want to join the queue?

", "time": "2023-03-28T00:56:15Z"}, {"author": "David Waite", "text": "

something like application/sd+jwt would confuse an implementation which wanted to process it as application/jwt - I don't think a +jwt suffix is appropriate

", "time": "2023-03-28T00:56:28Z"}, {"author": "David Waite", "text": "

compared to image/svg+xml, where it is entirely possible to interpret as application/xml

", "time": "2023-03-28T00:56:51Z"}, {"author": "Hannes Tschofenig", "text": "

I think we should talk to the experts on media types. There can easily be a lot of confusion for developers.

", "time": "2023-03-28T00:58:05Z"}, {"author": "Hannes Tschofenig", "text": "

Tony, on the JSON-LD issue: I would think that they hashed to the same disclosure. Do you have an example to look at?

", "time": "2023-03-28T01:00:37Z"}, {"author": "George Fletcher", "text": "

In both approaches there is the possibility for the array being malformed. Approach one could have multiple _sd entries. Approach 2 could have entries without a sd: prefix.

", "time": "2023-03-28T01:04:06Z"}, {"author": "Hannes Tschofenig", "text": "

Agree, George. But a parser would be able to recognize the issue

", "time": "2023-03-28T01:07:11Z"}, {"author": "George Fletcher", "text": "

Agree\u2026 I made the comment because one of the comments was an argument for approach one because in approach two an element in the array might not have the prefix. Also, it\u2019s more than a JSON parser and is really a SD-JWT syntax validator.

", "time": "2023-03-28T01:10:14Z"}, {"author": "Alexander Clouter", "text": "

Maybe for a service worker describe that \"storage used by the service worker should not be available to the main browser context of the application. Once suitable storage option is placing your service worker in different origin and using IndexDB.\".

", "time": "2023-03-28T01:20:01Z"}, {"author": "Alexander Clouter", "text": "

with the problem described as \"main browsing context MUST NOT be able to access storage of the service worker\" for a BCP should be okay

", "time": "2023-03-28T01:20:59Z"}, {"author": "Hannes Tschofenig", "text": "

agree

", "time": "2023-03-28T01:21:21Z"}, {"author": "George Fletcher", "text": "

That might be better with the FedCM work. I would recommend exploring the work going on in the FedID Community Group in the W3C.

", "time": "2023-03-28T01:21:25Z"}, {"author": "Richard Barnes", "text": "

WebCrypto already has non-exportable keys, and I'im pretty sure you could use those for DPoP

", "time": "2023-03-28T01:21:45Z"}, {"author": "Richard Barnes", "text": "

which i think is about as good as you're going to do here, practically speaking

", "time": "2023-03-28T01:21:55Z"}, {"author": "Kristina Yasuda", "text": "

cryptographic holder binding is what the specification focuses on right now - so it is not holder authentication, but whether the same cryptographic keys are controlled by the holder during the presentation as during the issuance.

", "time": "2023-03-28T01:22:25Z"}, {"author": "Hannes Tschofenig", "text": "

The WebCrypto API has come to my mind as well. I wonder whether this shouldn't be the way forward

", "time": "2023-03-28T01:22:32Z"}, {"author": "Anthony Nadalin", "text": "

Should look at PRF option on webauthn for the secure storage and crypto functions

", "time": "2023-03-28T01:23:09Z"}, {"author": "Richard Barnes", "text": "

if you're going to have something that is (a) non-stealable by XSS and (b) still presentable, then basically the only solution is cryptographic holder binding + non-exportable keys

", "time": "2023-03-28T01:23:16Z"}, {"author": "Kristina Yasuda", "text": "

cty JOSE Header can be used to signal the body is JSON-LD, but I agree there are more nuances do we mandate cty? what if we don't, cty is missing and @context is blinded? etc..

", "time": "2023-03-28T01:23:43Z"}, {"author": "Richard Barnes", "text": "

@Nadalin - Do you have a cite for that? would be interested to learn more about what you mean there

", "time": "2023-03-28T01:23:48Z"}, {"author": "Alexander Clouter", "text": "

for service workers, you need to avoid problem of shared 'memory' between the two environments (main browser and serviceworker); mostly means \"if you are using an API available to both and from the same origin...you are going to have a Bad Day(tm)\"

", "time": "2023-03-28T01:25:38Z"}, {"author": "Kristina Yasuda", "text": "

my first reaction was that both +sd+jwt and -sd+jwt would be misleading, the first one does not seem to have stable processing steps yet, and the second one is exactly what we want to avoid by introducing +sd-jwt, signalling to the developers that it is not +jwt...

", "time": "2023-03-28T01:25:46Z"}, {"author": "Hannes Tschofenig", "text": "

@Kristina: Looked up the draft again regarding the holder binding. Noticed that you clearly defined it in the draft. Makes sense now for me

", "time": "2023-03-28T01:26:22Z"}, {"author": "Kristina Yasuda", "text": "

agreed that we need to talk to media type experts, @Hannes Tschofenig, please let us know if there is anyone you have in mind :)

", "time": "2023-03-28T01:26:50Z"}, {"author": "Hannes Tschofenig", "text": "

@Kristina: There is a separate mailing list where the media type experts are. I would post a mail to that list -- media-types@iana.org (https://www.ietf.org/mailman/listinfo/media-types)

", "time": "2023-03-28T01:29:00Z"}, {"author": "George Fletcher", "text": "

In a consumer world, we don\u2019t really want to ask for a password\u2026 though I suppose with passkey maybe it\u2019s fine to reauthenticate the user :)

", "time": "2023-03-28T01:32:14Z"}, {"author": "Anthony Nadalin", "text": "

@Richard Barnes https://chromestatus.com/feature/5138422207348736

", "time": "2023-03-28T01:33:25Z"}, {"author": "Kristina Yasuda", "text": "

this is the FedCM CCG API documentation mentioned.. https://fedidcg.github.io/FedCM/#idp-api

", "time": "2023-03-28T01:34:10Z"}, {"author": "Hannes Tschofenig", "text": "

I agree with Vittorio that additional context is needed to explain the \"SHOULD NOT\"

", "time": "2023-03-28T01:39:59Z"}, {"author": "Anthony Nadalin", "text": "

Why is a DID specifically defined option ? There should not be a need

", "time": "2023-03-28T01:56:23Z"}, {"author": "Hannes Tschofenig", "text": "

Adding a kind of client ID scheme sounds simple but in the end it is a kind of a nightmare with all the different identifier types

", "time": "2023-03-28T01:58:10Z"}, {"author": "Hannes Tschofenig", "text": "

I worry about the interoperability

", "time": "2023-03-28T01:59:15Z"}, {"author": "Richard Barnes", "text": "

is this just DPoP without the D?

", "time": "2023-03-28T02:06:28Z"}, {"author": "Richard Barnes", "text": "

oh i see

", "time": "2023-03-28T02:08:30Z"}, {"author": "Richard Barnes", "text": "

:thumbsup: yeah let's finish it

", "time": "2023-03-28T02:08:40Z"}, {"author": "Richard Barnes", "text": "

seems like PoP is the wave of the future

", "time": "2023-03-28T02:08:47Z"}, {"author": "Kristina Yasuda", "text": "

there are certain ecosystems that use DIDs, and it is too early to rule them out as useless.

", "time": "2023-03-28T02:09:31Z"}, {"author": "Kristina Yasuda", "text": "

client_id_scheme is supposed to help with the interoperability ;)

", "time": "2023-03-28T02:09:56Z"}, {"author": "Kristina Yasuda", "text": "

one thing i didn't have time to mention was that the client_id_scheme is meant to co-exist with existing AS-managed/assigned client_ids. if there is no client_id_scheme, usual rfc6749 mechanism applies

", "time": "2023-03-28T02:11:18Z"}, {"author": "Kristina Yasuda", "text": "

(and indicating the client id scheme to the AS could make sense for closed ecosystems as it adds explicitness)

", "time": "2023-03-28T02:16:30Z"}, {"author": "Hannes Tschofenig", "text": "

I would recommend Nat to update the document and then we have the document to look at it

", "time": "2023-03-28T02:16:50Z"}, {"author": "Kristina Yasuda", "text": "

I am a little confused if there is no specific place from which this PoP draft needs to be referenced..

", "time": "2023-03-28T02:17:20Z"}, {"author": "Kristina Yasuda", "text": "

it should first probably be considered which aspects of this draft are not covered by DPoP security BCP, etc.

", "time": "2023-03-28T02:17:55Z"}, {"author": "Richard Barnes", "text": "

specifically where i would see it being referenced is as we evolve forward the PoP mechanism we have. Like if we replace DPoP signatures with HTTP Signing, it would be good to have language to say \"here's the part of the architecture we're swapping out, and why that's ok\"

", "time": "2023-03-28T02:19:16Z"}, {"author": "Anthony Nadalin", "text": "

Seems that the spiffe id document is overlap with DID

", "time": "2023-03-28T02:23:27Z"}, {"author": "Kristina Yasuda", "text": "

is there an example of a JWT SVID?

", "time": "2023-03-28T02:23:32Z"}, {"author": "Richard Barnes", "text": "

@Nadalin - DID is so gigantic that it overlaps with everything :)

", "time": "2023-03-28T02:23:49Z"}, {"author": "Richard Barnes", "text": "

just like in Java everything inherits from Object...

", "time": "2023-03-28T02:24:04Z"}, {"author": "Pieter Kasselman", "text": "

SVID JWT https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md

", "time": "2023-03-28T02:24:08Z"}, {"author": "Kristina Yasuda", "text": "

I think DIDs just embodies that need of a not-AS-managed-identifier.

", "time": "2023-03-28T02:24:19Z"}, {"author": "Hannes Tschofenig", "text": "

Where is the registry of DID schemes again?

", "time": "2023-03-28T02:26:43Z"}, {"author": "Anthony Nadalin", "text": "

Hannes Tschofenig said:

\n
\n

Where is the registry of DID schemes again?

\n
\n

You mean methods?

", "time": "2023-03-28T02:27:45Z"}, {"author": "Hannes Tschofenig", "text": "

yup

", "time": "2023-03-28T02:28:22Z"}, {"author": "Richard Barnes", "text": "

https://github.com/w3c/did-spec-registries

", "time": "2023-03-28T02:28:39Z"}, {"author": "Richard Barnes", "text": "

at last count, there were >200 methods

", "time": "2023-03-28T02:28:52Z"}, {"author": "Anthony Nadalin", "text": "

Not sure where this SPIFfE thing is going ...

", "time": "2023-03-28T02:28:54Z"}, {"author": "Richard Barnes", "text": "

Vittorio's point sounds pretty right to me. Handle the SPIFFE-relevant stuff in SPIFFE, handle any OAuth-generic stuff in OAuth

", "time": "2023-03-28T02:31:51Z"}, {"author": "Hannes Tschofenig", "text": "

With this topic we are still at an early exploration phase. We will have to figure out how the dots connect

", "time": "2023-03-28T02:32:42Z"}, {"author": "Kristina Yasuda", "text": "

I was talking about the context why DIDs emerged which might actually explain why there are >200 - maybe it's the process of consolidation around the best mechanism for not-AS-managed-identifiers.

", "time": "2023-03-28T02:32:50Z"}, {"author": "Richard Barnes", "text": "

Kristina - I would gladly buy you a beer over which to discuss this were I there in person :)

", "time": "2023-03-28T02:33:22Z"}]