inline this time...
On Mon, Sep 30, 2024 at 6:30 AM Dick Hardt wrote:
> I read over the W3C issue but it is not clear to me why using "typ" is an
> issue. I do see the issue that there is some possible name collision -- so
> perhaps someone does not get their first choice?
>
Yes and there are s
I read over the W3C issue but it is not clear to me why using "typ" is an
issue. I do see the issue that there is some possible name collision -- so
perhaps someone does not get their first choice?
A design objective of what became JOSE was to use JSON so that we did not
need to cram a bunch of me
Thanks for the additional explanation Dick,
The explicit typing construct is RECOMMENDED and not a MUST because there
exist perfectly legitimate cases where the construct is neither needed nor
appropriate. See https://github.com/w3c/vc-jose-cose/issues/282 for one
example where, amidst the noise i
Sorry Brian, I'll try again.
In the current text:
SD-JWTs are also potentially vulnerable to such confusion attacks, so it is
RECOMMENDED to specify an explicit type by including the typ header
parameter when the SD-JWT is issued, and for Verifiers to check this value.
It is only RECOMMENDED to
I must admit that I'm finding it difficult to fully grasp the points you're
making on this topic.. As with the other topics, there has been extensive
discussion about typing and media types[1]. And, while I have my own
reservations about using something inside a thing to say what the thing is
and t
My experience in developing standards is that framework specifications that
are not self contained lead to confusion.
I regret when I got back the pen for OAuth 2.0 that I did not merge what
became 6750 (bearer tokens) back into 6749. I'm atoning for my sins with
OAuth 2.1 which brings bearer toke
The reason why section 10.11 recommends JWT type to be defined by the
use-case is because SD-JWT specification is not meant only for one kind of
use-case/architecture. SD-JWT document does not define a stand alone
credential format for issuer-holder-verifier model, SD-JWT VC document is
intended to
But when you *don't* use the public key to secure more than a single type
of application message (unsurprisingly a very common use case), there is no
issue. Given that the current document defers to profiles all decisions
about which validation claims to require, which is a much more serious
likely
There are security issues from this however if the public key is used to secure more than a single type of application message - say a message normally used to indicate someone is logging out accidentally being accepted for log-in or as a valid session token on a website. In this scenario, you need
Hi,
If someone defines a new profile application/foobar-audit-system and it has
sd-jwt, jwt, and sd-cwt versions, it seems perfectly reasonable to have a
fine-grained explicit media type application/foobar-audit-system+sd-jwt.
That said, there are times when someone just wants an sd-jwt with an
uns
I am trying to make a few points. My reference to the BCP was on the
recommendation to do explicit typing. I'm suggesting that the sd-jwt
document state that include "typ" is a requirement, and to be explicit in
what that value should be.
I would suggest that value be "sd-jwt"
The "application+"
11 matches
Mail list logo
