Hi,
We have a machine-to-machine scenario where clients, RSes and our AS all belong
to different legal entities.
Some RSes require their clients to limit the access token to a specific
Resource Owner, while other RSes don't. In the former case, we use 'sub' to
identify that Resource Owner.
Thank you, Martin! RFC7523 was the reason for which i had the sub in the
first JWT AT profile draft the way I did. The proposal of requiring it only
for user flows and disallowing it otherwise is not in alignment with
RFC7523, which does not sound like a good thing, but ultimately the
function of J
Hi Dave,
either a type check or a lookup for client_id together with absence of sub
are going to be new logic- the latter seems to be more economical in term
of moving parts, without loss of expressive power.
I am not really committed to one model or the other, I just want to capture
the approach t
> On 26. Mar 2019, at 17:48, Vittorio Bertocci
> wrote:
>
> thank you Steinar and everyone else for the comments on this!
> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,
> Bertrand recommend using sub only for users. Martin would like to have the
> sub for app only f
great summary! this will hurt quite a few existing m2m deployments but I do
like the rigidness of it all: it is very explicit, cannot misinterpreted
and thus prevents failure (which is really what Dominick is after); I'm on
board
Hans.
On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci wrote:
>
Hi Vittorio
My understanding from Rob and others is that `sub` is already used for
tokens issued via the client credentials grant (in fact looking at the
tables from your presentation, most examples used `sub` for both user
identity and client identity). Given the desire for a spec that doesn't
br
Hi Neil,
thanks! This does sound very interesting. Just to clarify, you would
document this in a separate doc extending JOSE?
We could then mention it from the JWT AT profile, whihc would remain
lightweight and implementation independent.
thanks
V.
On Tue, Mar 26, 2019 at 3:11 AM Neil Madden
wrot
thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,
Bertrand recommend using sub only for users. Martin would like to have the
sub for app only flows as well. Hans is neutral.
That does sound like the sub as user has m
There are some deployments that I'm aware of that are considering using
draft-ietf-oauth-signed-http-request. Because of that, I've done a detailed
review of https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03,
which follows. Only substantive issues are discussed. If the draft
There was a brief discussion at OSW about signing vs encryption for JWT-based
access tokens. I think it was Brian Campbell that pointed out that you often
want authenticated encryption rather than signing, and I agree with this.
Currently JOSE only supports authenticated encryption for symmetric
Hi Vittorio, we (the national federation-gateway for the health services
in norway - "HelseID") think his is a really valuable initiative!
We also agree with Dominick concerning definition of the "sub" claim.
Steinar
tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier :
> From an access token co
I’d like to add my support for not proposing any change to how sub is
typically interpreted for client credentials tokens. In my experience the
usage of the client_id as the subject in this flow is well established and
it would cause disruption to many current implementations should that be
change
Thanks Vittorio for your presentation and putting this draft together.
I agree with Dominck that there is a potential of things going wrong when
`sub` has multiple meanings.
However I can see that using `sub` for a client_id semantically makes sense
in some situations and I agree that it makes it
Hi,
first time posting here but I have a comment on the "sub" claim:
We use RFC7523 for client authentication in a machine to machine scenario (i.e.
client credentials grant).
In this RFC, the JWT used as client assertion is defined that it "MUST contain
a "sub" (subject) claim identifying the
14 matches
Mail list logo
