I agree with Brian’s suggested text. Thanks for writing this, Brian!
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty
Sent: Saturday, July 19, 2014 7:28 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-jwt-bearer-09
Thanks, again! I read the other message first and the one comment is the same
to emphasize that you really should be encrypting to prevent disclosure.
Thanks,
Kathleen
Sent from my iPhone
On Jul 19, 2014, at 10:08 AM, Brian Campbell
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> wrote:
I agree that mentioning the RS in this context is only likely to cause
confusion.
This draft is only about sending a JWT to the token endpoint at an AS as an
authorization grant or as client authentication.
On Sat, Jul 19, 2014 at 6:37 AM, John Bradley
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote:
While a JWT might generically have many different audiences like resource
servers, this profile is about sending it to the token endpoint at an AS for
authentication or authorization.
I think adding something about the RS will confuse people.
I think Brian's text is fine.
John B.
On Jul 18, 2014, at 11:45 PM, Phil Hunt
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:
Should that be encrypted for the intended audience (aud) of the JWT which may
be the AS and/or the resource server?
Phil
On Jul 18, 2014, at 21:52, Brian Campbell
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> wrote:
Sorry for the slow response on this Kathleen, my day job has been keeping me
busy recently. And, honestly, I was kind of hopeful someone would volunteer
some text in the meantime. But that didn't happen so how about the following?
A JWT may contain privacy-sensitive information and, to prevent disclosure of
such information to unintended parties, should only be transmitted over
encrypted channels, such as TLS. In cases where it’s desirable to prevent
disclosure of certain information the client, the JWT may be be encrypted to
the authorization server.
Deployments should determine the minimum amount of information necessary to
complete the exchange and include only such claims in the JWT. In some cases
the "sub" (subject) claim can be a value representing an anonymous or
pseudonymous user as described in Section 6.3.1 of the Assertion Framework for
OAuth 2.0 Client Authentication and Authorization Grants
[http://tools.ietf.org/html/draft-ietf-oauth-assertions-16#section-6.3.1].
On Thu, Jul 3, 2014 at 3:26 PM, Kathleen Moriarty
<kathleen.moriarty.i...@gmail.com<mailto:kathleen.moriarty.i...@gmail.com>>
wrote:
Hello,
I just read through draft-ietf-oauth-jwt-bearer-09 and it looks good. The only
question/comment I have is that I don't see any mention of privacy
considerations in the referenced security sections. COuld you add something?
It is easily addressed by section 10.8 of RFC6749, but there is no mention of
privacy considerations. I'm sure folks could generate great stories about who
accessing what causing privacy considerations to be important.
Thanks & have a nice weekend!
--
Best regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
