Re: [OAUTH-WG] define a client_id JWT claim (in Token Exchange)?

+1 for “cid”, consistent with other JWT claims. — Justin > On Jun 20, 2016, at 5:21 PM, Brian Campbell > wrote: > > 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 clien

Re: [OAUTH-WG] nit RFC 7662 Errata?

It’s definitely a mistake, and I think an errata is the right track for it. Not positive though — chairs? — Justin > On Jun 20, 2016, at 5:02 PM, Brian Campbell > wrote: > > Some good irony in that message as I made a very similar mistake. The "IANA > Considerations RFC 7591 / Token Intros

Re: [OAUTH-WG] Token Exchange's act and may_act claims also registered for Introspection Endpoint responses?

Makes sense to me. — Justin > On Jun 20, 2016, at 2:46 PM, Brian Campbell > wrote: > > The question of if the act and may_act claims defined in Token Exchange > should also be registered/defined for Introspection Endpoint responses was > raised on this list a while back. Not much was said a

[OAUTH-WG] define a client_id JWT claim (in Token Exchange)?

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

Re: [OAUTH-WG] nit RFC 7662 Errata?

Some good irony in that message as I made a very similar mistake. The "IANA Considerations RFC 7591 / Token Introspection" link/text should say "IANA Considerations RFC 7591 / Client Registration ". Sigh. On Mon, Jun 20, 2016 at 2:37 PM, Brian Camp

[OAUTH-WG] nit RFC 7662 Errata?

Because of my earlier message about act and may_act also being registered for Introspection Endpoint responses I was looking at the IANA Considerations of RFC 7662 and it seems like some text in the 2nd paragraph of Sec 3.1

[OAUTH-WG] another open issue in Token Exchange: short names for some common token type identifiers

Another open issue in Token Exchange is the question of should there be a way to use short names for some common token type identifiers? URIs are necessary in the general case for extensibility and vendor/deployment specific types. But short names like access_token and jwt are aesthetically appeal

Re: [OAUTH-WG] closing an open issue about supplementary info in the Token Exchange request

Sounds appropriate From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, June 20, 2016 10:16 AM To: oauth Subject: [OAUTH-WG] closing an open issue about supplementary info in the Token Exchange request A good while back in an off list conversation about Token Ex

[OAUTH-WG] Token Exchange's act and may_act claims also registered for Introspection Endpoint responses?

The question of if the act and may_act claims defined in Token Exchange should also be registered/defined for Introspection Endpoint responses was raised on this list a while back. Not much was said about it at the time but I did put an issue in github to keep track of it. I'd like to close out tha

[OAUTH-WG] closing an open issue about supplementary info in the Token Exchange request

A good while back in an off list conversation about Token Exchange, Chuck Mortimore mentioned that they "had a use-case for custom claims in where they essentially wanted to carry along metadata about a client or device for association to objects in our cloud." As a result of that conversation I ad

[OAUTH-WG] OAuth Sessions @ IETF 96

Hi all, you may have seen that the preliminary agenda for the Berlin IETF meeting is available online at https://datatracker.ietf.org/meeting/96/agenda.html We have two OAuth WG meetings this time and they are scheduled for: - Monday, 14:00-15:30 - Wednesday, 15:50-17:20 Ciao Hannes signatu