Discussion:
[OAUTH-WG] define a client_id JWT claim (in Token Exchange)?
Brian Campbell
2016-06-20 21:21:30 UTC
Permalink
There is a somewhat poorly worded open issue in Token Exchange about being
able to represent the client in the token.

There is currently no standard claim for the client in JWT while Token
Introspection defines a "client_id" parameter. It's maybe not the ideal
place for it but Token Exchange could define such a claim for JWT.

I'm looking for some feedback from the WG on if/how to proceed with this in
Token Exchange. As I see it, there are basically 3 options:

1) Define and register a "client_id" JWT claim (consistent with the name in
Token Introspection) to carry the client id of the OAuth 2.0 client that
requested the token.

2) Define and register a "cid" JWT claim (consistent with the shorter names
typical for JWT) to carry the client id of the OAuth 2.0 client that
requested the token.

3) Do not define/register any new JWT claim for the client identifier (in
the Token Exchange draft anyway).

Feedback/preferences would be appreciated from the WG so as to make some
progress on the draft.

If pressed, I guess I'd lean towards option #1 myself.
Justin Richer
2016-06-20 22:22:13 UTC
Permalink
+1 for “cid”, consistent with other JWT claims.

— Justin
There is a somewhat poorly worded open issue in Token Exchange about being able to represent the client in the token.
There is currently no standard claim for the client in JWT while Token Introspection defines a "client_id" parameter. It's maybe not the ideal place for it but Token Exchange could define such a claim for JWT.
1) Define and register a "client_id" JWT claim (consistent with the name in Token Introspection) to carry the client id of the OAuth 2.0 client that requested the token.
2) Define and register a "cid" JWT claim (consistent with the shorter names typical for JWT) to carry the client id of the OAuth 2.0 client that requested the token.
3) Do not define/register any new JWT claim for the client identifier (in the Token Exchange draft anyway).
Feedback/preferences would be appreciated from the WG so as to make some progress on the draft.
If pressed, I guess I'd lean towards option #1 myself.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
John Bradley
2016-06-21 14:34:54 UTC
Permalink
I prefer “cid” as the claim name rather than trying to match the parameter name.

John B.
Post by Justin Richer
+1 for “cid”, consistent with other JWT claims.
— Justin
There is a somewhat poorly worded open issue in Token Exchange about being able to represent the client in the token.
There is currently no standard claim for the client in JWT while Token Introspection defines a "client_id" parameter. It's maybe not the ideal place for it but Token Exchange could define such a claim for JWT.
1) Define and register a "client_id" JWT claim (consistent with the name in Token Introspection) to carry the client id of the OAuth 2.0 client that requested the token.
2) Define and register a "cid" JWT claim (consistent with the shorter names typical for JWT) to carry the client id of the OAuth 2.0 client that requested the token.
3) Do not define/register any new JWT claim for the client identifier (in the Token Exchange draft anyway).
Feedback/preferences would be appreciated from the WG so as to make some progress on the draft.
If pressed, I guess I'd lean towards option #1 myself.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Chuck Mortimore
2016-06-21 15:35:02 UTC
Permalink
+1 for cid
Post by John Bradley
I prefer “cid” as the claim name rather than trying to match the parameter name.
John B.
Post by Justin Richer
+1 for “cid”, consistent with other JWT claims.
— Justin
There is a somewhat poorly worded open issue in Token Exchange about being able to represent the client in the token.
There is currently no standard claim for the client in JWT while Token Introspection defines a "client_id" parameter. It's maybe not the ideal place for it but Token Exchange could define such a claim for JWT.
1) Define and register a "client_id" JWT claim (consistent with the name in Token Introspection) to carry the client id of the OAuth 2.0 client that requested the token.
2) Define and register a "cid" JWT claim (consistent with the shorter names typical for JWT) to carry the client id of the OAuth 2.0 client that requested the token.
3) Do not define/register any new JWT claim for the client identifier (in the Token Exchange draft anyway).
Feedback/preferences would be appreciated from the WG so as to make some progress on the draft.
If pressed, I guess I'd lean towards option #1 myself.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Brian Campbell
2016-06-21 21:49:18 UTC
Permalink
Seems like there's roughly rough condenses for "cid". Thanks.
Post by Chuck Mortimore
+1 for cid
I prefer “cid” as the claim name rather than trying to match the
parameter name.
John B.
+1 for “cid”, consistent with other JWT claims.
— Justin
On Jun 20, 2016, at 5:21 PM, Brian Campbell <
There is a somewhat poorly worded open issue in Token Exchange about
being able to represent the client in the token.
There is currently no standard claim for the client in JWT while Token
Introspection defines a "client_id" parameter. It's maybe not the ideal
place for it but Token Exchange could define such a claim for JWT.
I'm looking for some feedback from the WG on if/how to proceed with
1) Define and register a "client_id" JWT claim (consistent with the
name in Token Introspection) to carry the client id of the OAuth 2.0 client
that requested the token.
2) Define and register a "cid" JWT claim (consistent with the shorter
names typical for JWT) to carry the client id of the OAuth 2.0 client that
requested the token.
3) Do not define/register any new JWT claim for the client identifier
(in the Token Exchange draft anyway).
Feedback/preferences would be appreciated from the WG so as to make
some progress on the draft.
If pressed, I guess I'd lean towards option #1 myself.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Brian Campbell
2016-06-22 15:34:00 UTC
Permalink
er... s:/condenses/consensus/
Seems like there's roughly rough condenses for "cid". Thanks.
Post by Chuck Mortimore
+1 for cid
I prefer “cid” as the claim name rather than trying to match the
parameter name.
John B.
+1 for “cid”, consistent with other JWT claims.
— Justin
On Jun 20, 2016, at 5:21 PM, Brian Campbell <
There is a somewhat poorly worded open issue in Token Exchange about
being able to represent the client in the token.
There is currently no standard claim for the client in JWT while Token
Introspection defines a "client_id" parameter. It's maybe not the ideal
place for it but Token Exchange could define such a claim for JWT.
I'm looking for some feedback from the WG on if/how to proceed with
1) Define and register a "client_id" JWT claim (consistent with the
name in Token Introspection) to carry the client id of the OAuth 2.0 client
that requested the token.
2) Define and register a "cid" JWT claim (consistent with the shorter
names typical for JWT) to carry the client id of the OAuth 2.0 client that
requested the token.
3) Do not define/register any new JWT claim for the client identifier
(in the Token Exchange draft anyway).
Feedback/preferences would be appreciated from the WG so as to make
some progress on the draft.
If pressed, I guess I'd lean towards option #1 myself.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Loading...