Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names
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 and the data stored at the AS (and out of scope of the
spec).
Thanks,
George
On 3/13/13 10:22 AM, Justin Richer wrote:
So with what little feedback I've gotten, I'm proposing to add text
from the proposed webfinger and OIDC drafts for the hash-based
localization of strings, with the following properties:
* All localized versions of fields are fully optional on both client
and server
* If a localized version of a field is included, its bare-value
(perhaps internationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including
any uri's for user-facing web pages, which can be used to point to
language-specific pages)
* Clients and servers can decide to use whatever language/script they
want to for the bare-value field, and no assumptions can be made on
either side about what that is
I think that with these constraints, we can add functionality to
address Stephen's concerns without getting too complicated or putting
too much burden of support.
-- Justin
On 03/11/2013 06:52 PM, Nat Sakimura wrote:
Similar work is in progress at Webfinger.
See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html
Paul is proposing the same syntax as Connect.
2013/3/12 Richer, Justin P. jric...@mitre.org
mailto:jric...@mitre.org
It does presume a definition of claim, which I suppose we could
turn to metadata field for DynReg and its extensions to be
appropriately limiting. But we also need a good definition of
what a language-tag-less field means, and whether or not it's
required if the other fields are present or not (which is
something that Connect is trying to fix at the moment, as I
recall from last week).
So it turns into about a paragraph worth of text. Is that worth
it? I'm not entirely convinced that it is, but I'm interested to
hear what others think, particularly those who *aren't* tied into
the OpenID Connect protocol so much. (I don't want to pick a
solution just because it's familiar, if we need a solution at all.)
-- Justin
On Mar 11, 2013, at 6:35 PM, Brian Campbell
bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com
wrote:
A fair question but what would need to be pulled in is really
probably only a couple sentences (and reference) from
http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts
(note the reference to 2.1.1.1.3 inside
http://openid.net/specs/openid-connect-registration-1_0-15.html
is broken)
On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P.
jric...@mitre.org mailto:jric...@mitre.org wrote:
My concern with this is that OIDC can get away with defining
this multi-language structure because it defines the
mechanism once (in Messages) and applies it to all
user-readable strings throughout the whole application
protocol, of which there are several. Do we really want to
pull in that whole structure and mechanism for one field in
client registration? I really don't think it should be
something that's defined completely inside of DynReg for a
corner case for a single field, but I also doubt we want to
normatively point to OIDC Messages for this solution either.
There are also other ways to do this: Webfinger [1] for
instance uses JSON structures to give language tags to field
values, and has a default mechanism:
{ en_us: my client, ... }
The fundamental question is this: should a client be able
to register multiple names (in different locales) with a
single client_id, or should it get a different client_id for
each display language set?
-- Justin
[1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11
On Mar 11, 2013, at 5:54 PM, John Bradley ve7...@ve7jtb.com
mailto:ve7...@ve7jtb.com
wrote:
That is what I was thinking. It would be up to the AS to
determine what language and script to present based on the
user preference.
While a large number of clients will be native and might be
able to customize themselves for a single user during
registration , we don't want to forget the web server
clients that are multi user.
On 2013-03-11, at 10:49 PM, Brian Campbell
bcampb...@pingidentity.com
mailto:bcampb...@pingidentity.com wrote:
FWIW, the closely related OpenID Connect client
registration draft does have some support for doing this,
which could maybe be borrowed. See client_name in §2
Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names
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 server that only looks for es-cl, there's a very real chance of the client name not getting set at all. I think that's a problem. This is why I think the default field name (without the language tag) really should be required and should be left undefined as to what language and script it is. Essentially, It's a UTF8 String, hope for the best. If you want something more specific and smart about localization, then you can support the language tags. If you just want to have a string to store and throw at the user, then you can just use the bare field name. In other words, we take what we have now (which works for a non-internationalized case where everyone just assumes a common language/script), and we augment it with features that let it be smarter if you want it to be smarter. Make the simple case simple, make the complicated case possible. -- Justin On 03/14/2013 10:47 AM, George Fletcher wrote: 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 and the data stored at the AS (and out of scope of the spec). Thanks, George On 3/13/13 10:22 AM, Justin Richer wrote: So with what little feedback I've gotten, I'm proposing to add text from the proposed webfinger and OIDC drafts for the hash-based localization of strings, with the following properties: * All localized versions of fields are fully optional on both client and server * If a localized version of a field is included, its bare-value (perhaps internationalized) field MUST be included * All human-readable fields are eligible for this mechanism (including any uri's for user-facing web pages, which can be used to point to language-specific pages) * Clients and servers can decide to use whatever language/script they want to for the bare-value field, and no assumptions can be made on either side about what that is I think that with these constraints, we can add functionality to address Stephen's concerns without getting too complicated or putting too much burden of support. -- Justin On 03/11/2013 06:52 PM, Nat Sakimura wrote: Similar work is in progress at Webfinger. See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html Paul is proposing the same syntax as Connect. 2013/3/12 Richer, Justin P. jric...@mitre.org mailto:jric...@mitre.org It does presume a definition of claim, which I suppose we could turn to metadata field for DynReg and its extensions to be appropriately limiting. But we also need a good definition of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is something that Connect is trying to fix at the moment, as I recall from last week). So it turns into about a paragraph worth of text. Is that worth it? I'm not entirely convinced that it is, but I'm interested to hear what others think, particularly those who *aren't* tied into the OpenID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution at all.) -- Justin On Mar 11, 2013, at 6:35 PM, Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com wrote: A fair question but what would need to be pulled in is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to 2.1.1.1.3 inside http://openid.net/specs/openid-connect-registration-1_0-15.html is broken) On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. jric...@mitre.org mailto:jric...@mitre.org wrote: My concern with this is that OIDC can get away with defining this multi-language structure because it defines the mechanism once (in Messages) and applies it to all user-readable strings throughout the whole application protocol, of which there are several. Do we really want to pull in that whole structure and mechanism for one field in client registration? I really don't think it should be something that's defined completely inside of DynReg for a corner case for a single field, but I also doubt we want to normatively point to OIDC Messages for this solution either. There are also other ways to do this: Webfinger [1] for instance uses JSON structures to give language tags to field
[OAUTH-WG] comment on draft-tschofenig-auth-audience-00.txt (incorrect use of audience)
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 indicating the address to which this request has been sent. This is useful to prevent malicious forwarding of requests to unintended recipients, a protection that is required by some protocol bindings. If it is present, the actual recipient MUST check that the URI reference identifies the location at which the message was received. If it does not, the request MUST be discarded. Some protocol bindings may require the use of this attribute (see [SAMLBind]). [\quote] In contrast, saml:audience is a means of /limiting the liability of the asserting party /and is described in the following manner - [quote-saml2.0] Audience A URI reference that identifies an intended audience. The URI reference MAY identify a document that describes the terms and conditions of audience membership. It MAY also contain the unique identifier URI from a SAML name identifier that describes a system entity (see Section 8.3.6). The audience restriction condition evaluates to Valid if and only if the SAML relying party is a member of one or more of the audiences specified. The SAML asserting party cannot prevent a party to whom the assertion is disclosed from taking action on the basis of the information provided. However, the AudienceRestriction element allows the SAML asserting party to state explicitly that no warranty is provided to such a party in a machine- and human-readable form. While there can be no guarantee that a court would uphold such a warranty exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably improved. [\quote] - prateek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names
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 parameter something like this one: registration_locale OPTIONAL or REQURED. Language and script used for human-readable values or references to human-readable values that are supplied without language/script tags, represented as a BCP47[RFC5646] language tag value. This parameter is REQUIRED if any human-readable values or references to human-readable are provided without language/script tags. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Thursday, March 14, 2013 8:02 AM To: George Fletcher Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names 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 server that only looks for es-cl, there's a very real chance of the client name not getting set at all. I think that's a problem. This is why I think the default field name (without the language tag) really should be required and should be left undefined as to what language and script it is. Essentially, It's a UTF8 String, hope for the best. If you want something more specific and smart about localization, then you can support the language tags. If you just want to have a string to store and throw at the user, then you can just use the bare field name. In other words, we take what we have now (which works for a non-internationalized case where everyone just assumes a common language/script), and we augment it with features that let it be smarter if you want it to be smarter. Make the simple case simple, make the complicated case possible. -- Justin On 03/14/2013 10:47 AM, George Fletcher wrote: 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 and the data stored at the AS (and out of scope of the spec). Thanks, George On 3/13/13 10:22 AM, Justin Richer wrote: So with what little feedback I've gotten, I'm proposing to add text from the proposed webfinger and OIDC drafts for the hash-based localization of strings, with the following properties: * All localized versions of fields are fully optional on both client and server * If a localized version of a field is included, its bare-value (perhaps internationalized) field MUST be included * All human-readable fields are eligible for this mechanism (including any uri's for user-facing web pages, which can be used to point to language-specific pages) * Clients and servers can decide to use whatever language/script they want to for the bare-value field, and no assumptions can be made on either side about what that is I think that with these constraints, we can add functionality to address Stephen's concerns without getting too complicated or putting too much burden of support. -- Justin On 03/11/2013 06:52 PM, Nat Sakimura wrote: Similar work is in progress at Webfinger. See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html Paul is proposing the same syntax as Connect. 2013/3/12 Richer, Justin P. jric...@mitre.orgmailto:jric...@mitre.org It does presume a definition of claim, which I suppose we could turn to metadata field for DynReg and its extensions to be appropriately limiting. But we also need a good definition of what a language-tag-less field means, and whether or not it's required if the other fields are present or not (which is something that Connect is trying to fix at the moment, as I recall from last week). So it turns into about a paragraph worth of text. Is that worth it? I'm not entirely convinced that it is, but I'm interested to hear what others think, particularly those who *aren't* tied into the OpenID Connect protocol so much. (I don't want to pick a solution just because it's familiar, if we need a solution at all.) -- Justin On Mar 11, 2013, at 6:35 PM, Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com wrote: A fair question but what would need to be pulled in is really probably only a couple sentences (and reference) from http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts (note the reference to 2.1.1.1.3 inside
Re: [OAUTH-WG] comment on draft-tschofenig-auth-audience-00.txt (incorrect use of audience)
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 On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: 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 indicating the address to which this request has been sent. This is useful to prevent malicious forwarding of requests to unintended recipients, a protection that is required by some protocol bindings. If it is present, the actual recipient MUST check that the URI reference identifies the location at which the message was received. If it does not, the request MUST be discarded. Some protocol bindings may require the use of this attribute (see [SAMLBind]). [\quote] In contrast, saml:audience is a means of limiting the liability of the asserting party and is described in the following manner - [quote-saml2.0] Audience A URI reference that identifies an intended audience. The URI reference MAY identify a document that describes the terms and conditions of audience membership. It MAY also contain the unique identifier URI from a SAML name identifier that describes a system entity (see Section 8.3.6). The audience restriction condition evaluates to Valid if and only if the SAML relying party is a member of one or more of the audiences specified. The SAML asserting party cannot prevent a party to whom the assertion is disclosed from taking action on the basis of the information provided. However, the AudienceRestriction element allows the SAML asserting party to state explicitly that no warranty is provided to such a party in a machine- and human-readable form. While there can be no guarantee that a court would uphold such a warranty exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably improved. [\quote] - prateek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth
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: Hannes Tschofenig; Mike Jones Cc: oauth@ietf.org Subject: the meaning of audience in SAML vs. OAuth Hannes - you make a good point. I believe that the usage of audience in http://www.ietf.org/id/draft-ietf-oauth-json-web-token-06.txt also corresponds to saml:destination rather than saml:audience. [quote-jwt06] The aud (audience) claim identifies the audiences that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in audience claim. If the principal processing the claim does not identify itself with a value in the aud claim, then the JWT MUST be rejected. In the general case, the aud value is an array of case sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the aud value MAY be a single case sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL. [\quote] I think this is a point of quite some confusion (a similar problem arose during the SAML assertion drafts discussion on Tuesday). To the extent that JWT re-uses concepts and names from SAML, I dont think this is the correct name with the semantics implied by the processing rules given in jwt06. - prateek 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 On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: 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 indicating the address to which this request has been sent. This is useful to prevent malicious forwarding of requests to unintended recipients, a protection that is required by some protocol bindings. If it is present, the actual recipient MUST check that the URI reference identifies the location at which the message was received. If it does not, the request MUST be discarded. Some protocol bindings may require the use of this attribute (see [SAMLBind]). [\quote] In contrast, saml:audience is a means of limiting the liability of the asserting party and is described in the following manner - [quote-saml2.0] Audience A URI reference that identifies an intended audience. The URI reference MAY identify a document that describes the terms and conditions of audience membership. It MAY also contain the unique identifier URI from a SAML name identifier that describes a system entity (see Section 8.3.6). The audience restriction condition evaluates to Valid if and only if the SAML relying party is a member of one or more of the audiences specified. The SAML asserting party cannot prevent a party to whom the assertion is disclosed from taking action on the basis of the information provided. However, the AudienceRestriction element allows the SAML asserting party to state explicitly that no warranty is provided to such a party in a machine- and human-readable form. While there can be no guarantee that a court would uphold such a warranty exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably improved. [\quote] - prateek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] the meaning of audience in SAML vs. OAuth
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 michael.jo...@microsoft.com: 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: Hannes Tschofenig; Mike Jones Cc: oauth@ietf.org Subject: the meaning of audience in SAML vs. OAuth Hannes - you make a good point. I believe that the usage of audience in http://www.ietf.org/id/draft-ietf-oauth-json-web-token-06.txt also corresponds to saml:destination rather than saml:audience. [quote-jwt06] The aud (audience) claim identifies the audiences that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in audience claim. If the principal processing the claim does not identify itself with a value in the aud claim, then the JWT MUST be rejected. In the general case, the aud value is an array of case sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the aud value MAY be a single case sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL. [\quote] I think this is a point of quite some confusion (a similar problem arose during the SAML assertion drafts discussion on Tuesday). To the extent that JWT re-uses concepts and names from SAML, I dont think this is the correct name with the semantics implied by the processing rules given in jwt06. - prateek 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 On Mar 14, 2013, at 11:34 AM, prateek mishra wrote: 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 indicating the address to which this request has been sent. This is useful to prevent malicious forwarding of requests to unintended recipients, a protection that is required by some protocol bindings. If it is present, the actual recipient MUST check that the URI reference identifies the location at which the message was received. If it does not, the request MUST be discarded. Some protocol bindings may require the use of this attribute (see [SAMLBind]). [\quote] In contrast, saml:audience is a means of limiting the liability of the asserting party and is described in the following manner - [quote-saml2.0] Audience A URI reference that identifies an intended audience. The URI reference MAY identify a document that describes the terms and conditions of audience membership. It MAY also contain the unique identifier URI from a SAML name identifier that describes a system entity (see Section 8.3.6). The audience restriction condition evaluates to Valid if and only if the SAML relying party is a member of one or more of the audiences specified. The SAML asserting party cannot prevent a party to whom the assertion is disclosed from taking action on the basis of the information provided. However, the AudienceRestriction element allows the SAML asserting party to state explicitly that no warranty is provided to such a party in a machine- and human-readable form. While there can be no guarantee that a court would uphold such a warranty exclusion in every circumstance, the probability of upholding the warranty exclusion is considerably improved. [\quote] - prateek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT grant_type and client_id
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 assertion. Is this correct? From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Monday, February 18, 2013 6:58 PM To: Lewis Adam-CAL022; oauth@ietf.org WG Subject: RE: JWT grant_type and client_id The client_id value and the access token value are independent. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Lewis Adam-CAL022 Sent: Monday, February 18, 2013 2:50 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] JWT grant_type and client_id Is there any guidance on the usage of client_id when using the JWT assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes no mention so I assume that it is not required ... but it would be necessary if using in conjunction with a HOK profile where the JWT assertion is issued to - and may only be used by - the intended client. Obviously this is straight forward enough, really I'm just looking to be sure that I'm not missing anything. tx adam ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT grant_type and client_id
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 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 assertion. Is this correct? ** ** ** ** *From:* Mike Jones [mailto:michael.jo...@microsoft.com] *Sent:* Monday, February 18, 2013 6:58 PM *To:* Lewis Adam-CAL022; oauth@ietf.org WG *Subject:* RE: JWT grant_type and client_id ** ** The client_id value and the access token value are independent. ** ** -- Mike*** * ** ** *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Lewis Adam-CAL022 *Sent:* Monday, February 18, 2013 2:50 PM *To:* oauth@ietf.org WG *Subject:* [OAUTH-WG] JWT grant_type and client_id ** ** ** ** Is there any guidance on the usage of client_id when using the JWT assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes no mention so I assume that it is not required … but it would be necessary if using in conjunction with a HOK profile where the JWT assertion is issued to – and may only be used by – the intended client. Obviously this is straight forward enough, really I’m just looking to be sure that I’m not missing anything. ** ** tx adam ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] JWT - typ and cty
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 would be able to tell without deep sniffing. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT grant_type and client_id
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 PM To: Lewis Adam-CAL022 Cc: Mike Jones; WG oauth@ietf.org@il06exr02.mot.com Subject: Re: [OAUTH-WG] JWT grant_type and client_id 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.commailto:adam.le...@motorolasolutions.com wrote: 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 assertion. Is this correct? From: Mike Jones [mailto:michael.jo...@microsoft.commailto:michael.jo...@microsoft.com] Sent: Monday, February 18, 2013 6:58 PM To: Lewis Adam-CAL022; oauth@ietf.orgmailto:oauth@ietf.org WG Subject: RE: JWT grant_type and client_id The client_id value and the access token value are independent. -- Mike From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On Behalf Of Lewis Adam-CAL022 Sent: Monday, February 18, 2013 2:50 PM To: oauth@ietf.orgmailto:oauth@ietf.org WG Subject: [OAUTH-WG] JWT grant_type and client_id Is there any guidance on the usage of client_id when using the JWT assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes no mention so I assume that it is not required ... but it would be necessary if using in conjunction with a HOK profile where the JWT assertion is issued to - and may only be used by - the intended client. Obviously this is straight forward enough, really I'm just looking to be sure that I'm not missing anything. tx adam ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] draft-ietf-oauth-json-web-token-06 comment
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 and/or encrypt the contents of the JWT. I believe it'd be useful to expand upon this to give guidance to those using JWT on what they should do to cryptographically protect it. When should they do nothing? When should they just sign? When should they just encrypt? When should they sign and then encrypt? What security properties does each option provide or not provide? The choices seem to be: 1. No JWS and no JWE - assumes the JWT is protected through some other mechanism or that it doesn't need to be protected 2. JWS - probably OK if confidentiality is not necessary. 3. JWE: Authentication is not provided unless a shared symmetric key is used (if it's asymmetric encryption, only integrity protection will be provided, not authentication). Under what conditions is authentication necessary or not necessary? AES-GCM may not be safe to use with a shared symmetric key (I sent feedback on this to the jose mailing list). draft-ietf-oauth-v2-http-mac for example seems to currently solely use JWE and says this keying material is a symmetric or asymmetric long-term key established between the resoruce server and authorization server. If it's asymmetric, a JWS seems to also be necessary to authenticate the authorization server as the source of the JWT? 4. JWS then JWE: A recipient who is an attacker/who is compromised could potentially strip off the JWE (making it just a JWS) or strip the JWE and replace it with another JWE to cause confusion about the intended recipient of the JWT and forward it on to another recipient. The presence of the aud (Audience) claim seems to protect against this. However, the aud claim is optional in JWTs. Thanks, Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-06 comment
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 used by people who are not experts in the subtleties of cryptography. I will endeavor to do this in subsequent drafts. If you have particular text that you believe should be incorporated, that would be highly appreciated. Best wishes, -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Peck, Michael A Sent: Thursday, March 14, 2013 8:05 PM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-json-web-token-06 comment 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 and/or encrypt the contents of the JWT. I believe it'd be useful to expand upon this to give guidance to those using JWT on what they should do to cryptographically protect it. When should they do nothing? When should they just sign? When should they just encrypt? When should they sign and then encrypt? What security properties does each option provide or not provide? The choices seem to be: 1. No JWS and no JWE - assumes the JWT is protected through some other mechanism or that it doesn't need to be protected 2. JWS - probably OK if confidentiality is not necessary. 3. JWE: Authentication is not provided unless a shared symmetric key is used (if it's asymmetric encryption, only integrity protection will be provided, not authentication). Under what conditions is authentication necessary or not necessary? AES-GCM may not be safe to use with a shared symmetric key (I sent feedback on this to the jose mailing list). draft-ietf-oauth-v2-http-mac for example seems to currently solely use JWE and says this keying material is a symmetric or asymmetric long-term key established between the resoruce server and authorization server. If it's asymmetric, a JWS seems to also be necessary to authenticate the authorization server as the source of the JWT? 4. JWS then JWE: A recipient who is an attacker/who is compromised could potentially strip off the JWE (making it just a JWS) or strip the JWE and replace it with another JWE to cause confusion about the intended recipient of the JWT and forward it on to another recipient. The presence of the aud (Audience) claim seems to protect against this. However, the aud claim is optional in JWTs. Thanks, Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
