Thanks for talking the time to reply to the individual comments, Mike.
The structure of the JWT doc is still flawed. The root cause is that JWT tries
to do three tasks:
1. Describe how a JOSE message can be a JWE or a JWS.
2. Describe how JOSE messages can nest (eg JWS in a JWE; JW
+1. Saving a few bytes in exchange to interoperability and security
possible downgrade does not seem to be a good strategy for me.
Nat
2014-03-12 7:04 GMT+09:00 Phil Hunt :
> I think that's the wrong perspective. If you intend the issuer to be the
> subject, you need to declare it.
>
> I wouldn
I think that's the wrong perspective. If you intend the issuer to be the
subject, you need to declare it.
I wouldn't worry that it duplicates issuer. The fields have different meaning.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2014-03-11, at 1:43 PM, Antonio Sanso wrot
agree, but in some cases the subject is not only same as the issuer but simply
it doesn’t matter.
In my example below all it matters is that the assertion signed by app1 is
valid….
Continue in my probably not relevant “Google example” if I set the prn same as
the issuer it would not work (kee
Company X will likely care about the subject being asserted by company A for
auditing and possible revocation.
It may be that the extension claim accessLevel=Accounting is sufficient to
grant the access token.
By Policy A could make sub itself, or an identifier for the user of the client
in
Hi,
perhaps you can show that I'm wrong, but I still think, that there are
cases, where the subject is unknown cause it's not relevant. Let's consider
the following federation-scenario:
1. Bob has a Token T1 that says, that he works for Company A on Project B.
The Subject of this token is "Bob".
The specification is intended to allow the interoperation of standard
libraries.
In some cases the subject and the iss may be the same, however the underlying
OAuth library may be a general one and always require a subject for security
processing.
It is possible that all libraries could have
This is a Last Call for comments on
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07
Please have your comments in no later than March 25th.
It is a fairly short document - have a look at it.
Thanks!
Hannes & Derek
signature.asc
Description: OpenPGP digital signature
_
Ok this is my use case:
- I am John Doe and going to AS to register my app named app1
- I then either upload my public key or download a private key
- at this point I am ready to build my assertion, the issuer claim is going to
be app1 and should suffice.
is the subject really needed in this us
The missing scheme especially on JWT issued by google is something I understand
they are working on but need to be careful about breaking existing code, so
will possibly need new endpoints that are spec compliant.
While in this google case the subject and the issuer happen to be the same they
Maintaining both information in the JWT is IMHO valuable since it gives
you some information about the security properties. Needless to say that
there is a substantial difference between a self-created JWT and a JWT
from a third party the relying party has some confidence in.
Why Google has an old
On Mar 11, 2014, at 3:53 PM, Hannes Tschofenig
wrote:
> Thanks for clarifying.
>
> I took a quick look at the Google API and it seems that in their use
> case the client creates the JWT and consequently the subject and the
> issue would actually be the same. I suspect that this is the reason w
Thanks for clarifying.
I took a quick look at the Google API and it seems that in their use
case the client creates the JWT and consequently the subject and the
issue would actually be the same. I suspect that this is the reason why
they omitted the subject.
Could you explain why you would like t
hi Hannes,
I am aware of the 2 documents,
I might be wrong but http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07
is also about Authorization Grant Processing (this is the part I do use in my
implementation ) and not only Client Authentication Processing.
Just my 0.02 $ but this seems t
Hi Manfred, Hi Antonio,
Note that there are two documents that talk about the JWT and you guys
might be looking at the wrong document.
The main JWT document (see
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18) defines
the subject claim as optional (see Section 4.1.2).
The JWT bear
Hi Antonio,
some time ago, I wrote about the same issue, but unfortunately didnt
get an answer. I place my thoughts about this at the end of this mail.
Wishes,
Manfred
8<---
Hi,
the draft about the
JWT Profile for OAuth 2.0 Client Authent
hi *,
JSON Web Token (JWT) Profile section 3 [0] explicitely says
The JWT MUST contain a "sub" (subject) claim
Now IMHO there are cases where having the sub is either not needed or redundant
(since it might overlap with the issuer).\
As far as I can see “even Google” currently violates this s
17 matches
Mail list logo
