As a simplifying option... why not just require human-readable fields to
require a script-tag. This way it is always explicit what
language/locale the text is for. It then becomes the responsibility of
the AS to return an appropriate response if there is not a direct match
between a request
On the surface this does simplify things, but the issue I forsee with it
is that I want to be able to call client.getClientName() and always
get *something* out of it if there are *any* client_name fields at all.
So in this world if I take a client library that assumes en-us and it
talks to a
Hi Hannes,
I wanted to point out that use of the term audience in this document
is not consistent with the SAML 2.0 specification.
What you are referring to here as audience corresponds to
saml:destination which is described as
[quote-saml2.0]
Destination [Optional]
A URI reference
I agree that having unadorned values likely simplifies things in many cases,
but if we do this, we should let the Client say what language/script it’s using
when providing human-readable strings or references to them as registration
parameters. For this purpose, I’d propose that we have a
Hi Prateek,
I never had planned to make the term audience to align with the SAML
specification.
However, in case this could lead to confusion we could also define a different
term.
Btw, did you look at the JWT spec whether the audience term there is inline
with the SAML spec?
Ciao
Hannes
The JWT meaning of the term audience is intended to be the same as SAML.
Suggested wording clarifications would be welcomed.
-- Mike
-Original Message-
From: prateek mishra [mailto:prateek.mis...@oracle.com]
Sent: Thursday, March 14, 2013 11:53 AM
To:
well.. the aud term came from googler's use of the term and not saml.
I agree with Prateek that the intention of the jwt:aud is rather
similar to saml:destination.
JWT is imposing the processing rule on it while saml:audience is
mainly concerned about the liability.
Nat
2013/3/15 Mike Jones
Coming back to this ... am I correct in that client_id is not required? We are
implementing this spec and want to make sure that we are doing it right. By my
understanding the only two parameters that are required in the JWT grant type
are urn:ietf:params:oauth:grant-type:jwt-bearer and the
Yes, that is correct.
I'm working on new revisions of the drafts that will hopefully make that
point more clear.
On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022
adam.le...@motorolasolutions.com wrote:
Coming back to this … am I correct in that client_id is not required? We
are
In the interest of time, I did not follow up in the WG F2F, but the if
cty=JWT for both JWE and JWS still bothers me.
Yes, it can be unambiguously identify if the content is JWS or JWE,
but to do that, you have to sniff the body of the decoded JWT.
If we had typ=JWT+JWS etc. or cty=JWT+JWS, it
Hmmm, one more thought ... no scope?? The JWT is the grant, is it assumed that
the scope is conveyed as a claim within the token? Otherwise it would seem
that it would require a scope.
Thoughts?
adam
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, March 14, 2013 4:44
To explain my comment at the microphone today:
Section 8 states:
JWTs use JSON Web Signature (JWS)
[JWShttp://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#ref-JWS]
and JSON Web Encryption (JWE)
[JWEhttp://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#ref-JWE] to
sign
Hi Mike. I appreciate your comments. Recently, Jeff Hodges and Brad Hill have
made related comments about the desirability of providing additional guidance
to implementers as to what security properties different choices give. I agree
with you - especially recognizing that the specs will be
13 matches
Mail list logo
