Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

[Bill Jung]

Yep, I agree. But that's just me agreeing with it. Unless the spec clearly
says it everybody will throw different ideas and use cases. That's why I
want the spec to clarify this.

On Wed, Mar 4, 2020, 1:42 PM Justin Richer,  wrote:

> Why would the client need to know the refresh token’s expiry? Can’t they
> just use the refresh token and see? Either way it’s a single round trip to
> the AS and the client gets the same answer with the same recovery code path.
>
>  — Justin
>
> On Mar 4, 2020, at 2:01 PM, Bill Jung <
> bjung=40pingidentity@dmarc.ietf.org> wrote:
>
> The question started when some RPs (client apps) asked that AS allow
> introspection endpoint to RPs so that RPs can check their refresh
> token's expiry. If AS allows this, which the spec is not clear about, then
> AS needs to know if the request is coming from RP or RS so that AS can
> allow the Access Token introspection to RS only. But then is that the right
> thing to do even?
>
> Surely some clarification will eliminate the time spent on unnecessary
> discussion among developers.
>
> [image: Ping Identity]
> 
> Bill Jung
> Manager, Response Engineering
> bj...@pingidentity.com
> w: +1 604.697.7037
> Connect with us: [image: Glassdoor logo]
> 
>  [image:
> LinkedIn logo]   [image: twitter
> logo]  [image: facebook logo]
>  [image: youtube logo]
>   [image: Blog logo]
> 
> 
> 
> 
>
>
> On Sun, Mar 1, 2020 at 9:33 PM David Waite  40alkaline-solutions@dmarc.ietf.org> wrote:
>
>> On Mar 1, 2020, at 10:11 PM, Andrii Deinega 
>> wrote:
>> >
>> > How would the authorization server know who actually uses the
>> > introspection endpoint assuming that a protected resource and a client
>> > application use the same credentials (client_id and client_secret)?
>>
>> In the external context, you have a client accessing a protected resource
>> with an access token. The client should treat the token as opaque, and
>> RFC7662 makes no allowances for that client to introspect its tokens.
>>
>> If you control both the client and protected resource, you may decide to
>> short-cut and have them share credentials. However, the client logic still
>> should never be introspecting the tokens.
>>
>> The security considerations also say that you must prove the
>> authentication of the protected resource, which I have interpreted to mean
>> that access tokens used to authorize the call to the introspection endpoint
>> must be issued to a confidential client - public clients cannot protect
>> credentials to perform an authentication. You want to limit introspection
>> to prevent denial of service and probing attacks, and to limit the amount
>> of information on viable attacks conveyed if someone steals a token.
>>
>> -DW
>>
>> >
>> > Regards,
>> > Andrii
>> >
>> > On Sun, Mar 1, 2020 at 7:38 PM David Waite <
>> da...@alkaline-solutions.com> wrote:
>> >>
>> >> I would expect the AS to invalidate the refresh token in this case,
>> which would not require a refresh token mode nor necessarily any signaling
>> back to the resource.
>> >>
>> >> -DW
>> >>
>> >>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega 
>> wrote:
>> >>>
>> >>> Hello Bill,
>> >>>
>> >>> I'm just thinking out loud about possible scenarios for a protected
>> >>> resource here... It may decide to revoke a refresh token if a client
>> >>> application tried to use it instead of an access token when the
>> >>> protected resource is paranoid about security. In order to do that an
>> >>> introspection response should include a non-standard parameter which
>> >>> indicates that the requested token is refresh_token.
>> >>>
>> >>> A user of the introspection endpoint should rely only on a value of
>> >>> the active parameter (which is a boolean indicator) of the endpoint
>> >>> response. This applies to both types of tokens. Note, the expiration
>> >>> date, as well as other parameters, are defined as optional in the
>> >>> specification. Both token types can be revoked before the expiration
>> >>> date comes even if this parameter is presented as part of the
>> >>> response. In my opinion, there are a number of reasons why this check
>> >>> (for a refresh token) can be useful on the client application side.
>> >>>
>> >>> --
>> >>> Regards,
>> 

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

[Justin Richer]

Why would the client need to know the refresh token’s expiry? Can’t they just 
use the refresh token and see? Either way it’s a single round trip to the AS 
and the client gets the same answer with the same recovery code path.

 — Justin

> On Mar 4, 2020, at 2:01 PM, Bill Jung 
>  wrote:
> 
> The question started when some RPs (client apps) asked that AS allow 
> introspection endpoint to RPs so that RPs can check their refresh token's 
> expiry. If AS allows this, which the spec is not clear about, then AS needs 
> to know if the request is coming from RP or RS so that AS can allow the 
> Access Token introspection to RS only. But then is that the right thing to do 
> even? 
> 
> Surely some clarification will eliminate the time spent on unnecessary 
> discussion among developers. 
> 
>    
> Bill Jung 
> Manager, Response Engineering 
> bj...@pingidentity.com 
> w: +1 604.697.7037
> Connect with us:   
> 
>     
>    
>  
>   
>  
> 
>   
> 
> 
> On Sun, Mar 1, 2020 at 9:33 PM David Waite 
>  > wrote:
> On Mar 1, 2020, at 10:11 PM, Andrii Deinega  > wrote:
> > 
> > How would the authorization server know who actually uses the
> > introspection endpoint assuming that a protected resource and a client
> > application use the same credentials (client_id and client_secret)?
> 
> In the external context, you have a client accessing a protected resource 
> with an access token. The client should treat the token as opaque, and 
> RFC7662 makes no allowances for that client to introspect its tokens.
> 
> If you control both the client and protected resource, you may decide to 
> short-cut and have them share credentials. However, the client logic still 
> should never be introspecting the tokens.
> 
> The security considerations also say that you must prove the authentication 
> of the protected resource, which I have interpreted to mean that access 
> tokens used to authorize the call to the introspection endpoint must be 
> issued to a confidential client - public clients cannot protect credentials 
> to perform an authentication. You want to limit introspection to prevent 
> denial of service and probing attacks, and to limit the amount of information 
> on viable attacks conveyed if someone steals a token.
> 
> -DW
> 
> > 
> > Regards,
> > Andrii
> > 
> > On Sun, Mar 1, 2020 at 7:38 PM David Waite  > > wrote:
> >> 
> >> I would expect the AS to invalidate the refresh token in this case, which 
> >> would not require a refresh token mode nor necessarily any signaling back 
> >> to the resource.
> >> 
> >> -DW
> >> 
> >>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega  >>> > wrote:
> >>> 
> >>> Hello Bill,
> >>> 
> >>> I'm just thinking out loud about possible scenarios for a protected
> >>> resource here... It may decide to revoke a refresh token if a client
> >>> application tried to use it instead of an access token when the
> >>> protected resource is paranoid about security. In order to do that an
> >>> introspection response should include a non-standard parameter which
> >>> indicates that the requested token is refresh_token.
> >>> 
> >>> A user of the introspection endpoint should rely only on a value of
> >>> the active parameter (which is a boolean indicator) of the endpoint
> >>> response. This applies to both types of tokens. Note, the expiration
> >>> date, as well as other parameters, are defined as optional in the
> >>> specification. Both token types can be revoked before the expiration
> >>> date comes even if this parameter is presented as part of the
> >>> response. In my opinion, there are a number of reasons why this check
> >>> (for a refresh token) can be useful on the client application side.
> >>> 
> >>> --
> >>> Regards,
> >>> Andrii
> >>> 
> >>> 
> >>> On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
> >>>  >>> > wrote:
>  
>  Hello, hopefully I am using the right email address.
>  
>  Simply put, can this spec be enhanced to clarify "Who can use the 
> 

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

[Justin Richer]

I can see the confusion in interpreting these requirements together. However, 
this is giving a specific semantics to omitted fields such that they’re treated 
as included in a specific way — with a null value. The intent of “include 
everything” is that you don’t leave out values and expect them to not change. 
Instead we define explicitly what happens when you leave out values — they get 
deleted, effectively. 

 — Justin

> On Mar 4, 2020, at 1:20 PM, Filip Skokan  wrote:
> 
> I guess what i meant to call out is that while you and the spec says how 
> omitted fields should be handled, but in the same section earlier it states 
> that all fields must be included.
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Wed, 4 Mar 2020 at 17:35, Justin Richer  > wrote:
> I’m not sure what you’re asking — the text is not left over from anything and 
> is intentionally included. That text is saying that if I leave out the field 
> then the server treats it just like as if I had sent in a null value. So the 
> following are equivalent:
> 
> {
>   “client_name”: “foo”,
>   “tos_uri”: null
> }
> 
> And 
> 
> {
>   “client_name”: “foo”,
> }
> 
> 
> In both cases, it’s a signal that the client is removing the value from the 
> “tos_uri” field. It does not mean that the AS leaves the “tos_uri” field with 
> the value that it previously was (ie, a PATCH style request). 
> 
> The AS can reject the update request if it doesn’t want to allow the client 
> to blank out that field, for whatever reason. 
> 
>  — Justin
> 
> 
>> On Mar 4, 2020, at 10:42 AM, Filip Skokan > > wrote:
>> 
>> So the following
>> 
>> Omitted fields MUST be treated as null or empty values by the server, 
>> indicating the client's request to delete them from the client's 
>> registration.
>> 
>> Does not mean the server needs to accept requests where fields are omitted? 
>> Is that a left over from previous drafts then?
>> 
>> S pozdravem,
>> Filip Skokan
>> 
>> 
>> On Wed, 4 Mar 2020 at 16:37, Justin Richer > > wrote:
>> Your interpretation was our intent with that. It’s a full replace of the 
>> object. We had debating having PATCH style semantics, but ultimately decided 
>> that that was too complex for the most common update actions that a client 
>> would have.
>> 
>>  — Justin
>> 
>>> On Mar 3, 2020, at 8:42 AM, Filip Skokan >> > wrote:
>>> 
>>> Hello everyone,
>>> 
>>> Section 2.2 of RFC 7592  
>>> (Dynamic Client Registration Management Protocol) has the following two 
>>> statements that oppose one another.
>>> 
>>> This request MUST include all client metadata fields as returned to the 
>>> client from a previous registration, read, or update operation.
>>> 
>>> Omitted fields MUST be treated as null or empty values by the server, 
>>> indicating the client's request to delete them from the client's 
>>> registration.
>>> 
>>> What's the intention here? Should a server be accepting requests that are 
>>> missing client properties it has either on the record or "resolved" or not?
>>> 
>>> Personally I like to always make sure the client submits everything and to 
>>> remove properties it must pass null or empty string as the values. That way 
>>> the request is 100% intentional about the final state of the record it 
>>> wants to update to.
>>> 
>>> What do you think?
>>> 
>>> Best,
>>> Filip
>>> ___
>>> 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

Re: [OAUTH-WG] OAuth and OpenID Connect enterprise profiles

[Peck, Michael A]

Daniel,

Thank you for your feedback!

We’re definitely interested in aligning with FAPI and with the proposed OAuth 
2.1, as that could greatly simplify what we need to specify in our enterprise 
profiles if we can point to one or both as a baseline, and help provide a 
common set of requirements for implementations.  We’ll compare with the FAPI 
2.0 Baseline profile and bring any specific comments over to its mailing list.

Generally we stated requirements as mandatory that we believe many current 
implementations already can meet, and stated requirements as recommended that 
we want to encourage implementations to meet. For example PKCE seems to be 
widely implemented by authorization servers but not yet by many clients. 
Certainly we’re open to input, and I’m glad to see the strict requirements that 
are in the current version of the FAPI 2.0 Baseline profile.

By “front-end web server” we mean a user-facing (user connects to it from their 
browser) web server (running on a separate endpoint from the user 
agent/browser). The web server is acting as an OAuth client to call a backend 
protected resource (such as a database) on behalf of the user and generally 
presenting the results back to the user agent/browser.  We will try to clarify 
our terminology. This use case is described in our profile’s section 1.5.1. 
(Part of the motivation of our use case text is to describe how OAuth can 
address enterprise needs to those who may be unfamiliar with OAuth.)

We’ll fix section 3.7, thanks!

That’s a good point about Section 6 of our profile and the Security BCP. We 
already took the contents of the Security BCP into account throughout the 
profile. One thought is to just remove our Section 6, as the TLS requirement is 
already stated elsewhere, and the blanket statements to comply with RFC6749 and 
RFC6819 appear redundant and could complicate compliance testing.

Thanks,
Mike


From: Daniel Fett 
Date: Tuesday, March 3, 2020 at 9:17 AM
To: Michael Peck , "oauth@ietf.org" 
Cc: OAuthOIDCProfiles 
Subject: [EXT] Re: [OAUTH-WG] OAuth and OpenID Connect enterprise profiles

Hi Michael et al., 

Thanks for the document, it is an interesting read! I like the "Security 
Rationale" section in particular. Very useful!

In general, this seems to go into a similar direction as the FAPI 2.0 Baseline 
profile we are currently developing in the FAPI WG [1]. It might be worthwhile 
to compare the two.

Some other points from a first read:
(All page numbers as printed, not the PDF page count.)

- Why is PKCE not mandatory for confidential clients? It provides a strong 
second layer of defense when authorization codes are stolen.

- I found the description "front-end web server application" somewhat confusing 
(Section 2.1.1, p. 9) - The client runs on the server's backend, I assume? On 
the front-end (browser), it should be a public client.
- In Section 3.7 (p. 22), the first and second paragraph seem to contradict 
each other. First one says "RECOMMENDED lifetimes", second one says "MUST have 
a valid lifetime no greater than one hour". 
- I was surprised that the Security BCP does not show up in Section 6.

-Daniel

[1] https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md




Am 02.03.20 um 20:53 schrieb Peck, Michael A:
Hello all,

For anyone who may be interested: MITRE, in support of the U.S. Government, has 
developed tailored OAuth and OpenID Connect profiles for use in enterprise 
environments. We have leveraged previous standards efforts (e.g. work in the 
IETF and in the OpenID Foundation) and have detailed requirements to use the 
standards in a secure and interoperable manner to address enterprise 
environment use cases.

These profiles should be considered informational as we seek feedback from 
subject matter experts. We’re interested in working with standards bodies and 
others to move these concepts forward. We welcome any comments and suggestions 
at mailto:oauthoidcprofi...@groups.mitre.org .

The profiles can be found at: 
https://www.mitre.org/publications/technical-papers/enterprise-mission-tailored-oauth-20-and-openid-connect-profiles

Michael Peck
The MITRE Corporation

___
OAuth mailing list
mailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-03-09

[Brian Campbell]

Here's a link to DPoP in the fancy new HTML format
https://www.ietf.org/id/draft-fett-oauth-dpop-04.html

On Thu, Feb 27, 2020 at 12:40 PM Daniel Fett  wrote:

> What about DPoP?
>
> -Daniel
>
> Am 27.02.20 um 18:51 schrieb IESG Secretary:
>
> The Web Authorization Protocol (oauth) Working Group will hold
> a virtual interim meeting on 2020-03-09 from 18:00 to 19:30 Europe/Vienna..
>
> Agenda:
> This meeting is setup to discuss proof-of-possession tokens.
>
> Several documents are relevant to this discussion, including 
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03https://tools.ietf.org/html/draft-richanna-oauth-http-signature-pop-00https://tools.ietf.org/html/draft-cavage-http-signatures-12https://tools.ietf.org/html/rfc8613https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07https://tools.ietf.org/html/rfc7800https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33https://tools.ietf.org/html/draft-ietf-oauth-mtls-17
>
> Information about remote 
> participation:https://ietf.webex.com/ietf/j.php?MTID=m9fc3ef4d116ad78e120c520eda96b269
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

[Bill Jung]

The question started when some RPs (client apps) asked that AS allow
introspection endpoint to RPs so that RPs can check their refresh
token's expiry. If AS allows this, which the spec is not clear about, then
AS needs to know if the request is coming from RP or RS so that AS can
allow the Access Token introspection to RS only. But then is that the right
thing to do even?

Surely some clarification will eliminate the time spent on unnecessary
discussion among developers.

[image: Ping Identity]

Bill Jung
Manager, Response Engineering
bj...@pingidentity.com
w: +1 604.697.7037
Connect with us: [image: Glassdoor logo]

[image:
LinkedIn logo]  [image: twitter
logo]  [image: facebook logo]
 [image: youtube logo]
 [image: Blog logo]






On Sun, Mar 1, 2020 at 9:33 PM David Waite  wrote:

> On Mar 1, 2020, at 10:11 PM, Andrii Deinega 
> wrote:
> >
> > How would the authorization server know who actually uses the
> > introspection endpoint assuming that a protected resource and a client
> > application use the same credentials (client_id and client_secret)?
>
> In the external context, you have a client accessing a protected resource
> with an access token. The client should treat the token as opaque, and
> RFC7662 makes no allowances for that client to introspect its tokens.
>
> If you control both the client and protected resource, you may decide to
> short-cut and have them share credentials. However, the client logic still
> should never be introspecting the tokens.
>
> The security considerations also say that you must prove the
> authentication of the protected resource, which I have interpreted to mean
> that access tokens used to authorize the call to the introspection endpoint
> must be issued to a confidential client - public clients cannot protect
> credentials to perform an authentication. You want to limit introspection
> to prevent denial of service and probing attacks, and to limit the amount
> of information on viable attacks conveyed if someone steals a token.
>
> -DW
>
> >
> > Regards,
> > Andrii
> >
> > On Sun, Mar 1, 2020 at 7:38 PM David Waite 
> wrote:
> >>
> >> I would expect the AS to invalidate the refresh token in this case,
> which would not require a refresh token mode nor necessarily any signaling
> back to the resource.
> >>
> >> -DW
> >>
> >>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega 
> wrote:
> >>>
> >>> Hello Bill,
> >>>
> >>> I'm just thinking out loud about possible scenarios for a protected
> >>> resource here... It may decide to revoke a refresh token if a client
> >>> application tried to use it instead of an access token when the
> >>> protected resource is paranoid about security. In order to do that an
> >>> introspection response should include a non-standard parameter which
> >>> indicates that the requested token is refresh_token.
> >>>
> >>> A user of the introspection endpoint should rely only on a value of
> >>> the active parameter (which is a boolean indicator) of the endpoint
> >>> response. This applies to both types of tokens. Note, the expiration
> >>> date, as well as other parameters, are defined as optional in the
> >>> specification. Both token types can be revoked before the expiration
> >>> date comes even if this parameter is presented as part of the
> >>> response. In my opinion, there are a number of reasons why this check
> >>> (for a refresh token) can be useful on the client application side.
> >>>
> >>> --
> >>> Regards,
> >>> Andrii
> >>>
> >>>
> >>> On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
> >>>  wrote:
> 
>  Hello, hopefully I am using the right email address.
> 
>  Simply put, can this spec be enhanced to clarify "Who can use the
> introspection endpoint for a refresh token? A resource provider or a client
> app or both?"
> 
>  RFC7662 clearly mentions that the user of introspection endpoint is a
> 'protected resource' and that makes sense for an access token. If we allow
> this to client apps, it'll give unnecessary token information to them.
>  However, the spec also mentions that refresh tokens can also be used
> against the endpoint.
>  In case of refresh tokens, user of the endpoint should be a client
> app because refresh tokens are used

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

[Bill Jung]

Yes, actually the term "protected resource" is awkward. It is the resource
server's jog to introspect tokens to protect those protected resources.

[image: Ping Identity]

Bill Jung
Manager, Response Engineering
bj...@pingidentity.com
w: +1 604.697.7037
Connect with us: [image: Glassdoor logo]

[image:
LinkedIn logo]  [image: twitter
logo]  [image: facebook logo]
 [image: youtube logo]
 [image: Blog logo]






On Fri, Feb 28, 2020 at 6:55 AM David Skaife <
blue.ringed.octopus@gmail.com> wrote:

> Hi,
>
> In additional to Bill's query, the use of the term "protected resource" in
> the context of RFC7662 is quite confusing. As defined by RFC6749 (which
> RFC7662 defers to for definition of the terms), the term "protected
> resource" is defined as an "access-restricted resource" that a client can
> request.. In the context of RFC7662, it doesn't make sense for an
> "access-restricted resource" to be making any requests to the introspection
> endpoints - surely it is the resource server that is the intended consumer
> of the introspection endpoints? This is also backed up by Section 4
> (Security Considerations) of RFC7662 which reverts to using the term
> "resource server" as the consumer of the introspection endpoints.
> For example, in these quotes:
> "However, since resource servers using token introspection rely on the 
> authorization
> server to determine the state of a token.." and
> "...the authorization server MUST determine whether or not the token can be
> used at the resource server making the introspection call"
>
> Apologies if I've misinterpreted something here, but if RFC7662 has a
> different meaning for the term "protected resource" from RFC6749 then it
> should be stated clearly within that document. I also agree with Bill's
> observation that it doesn't make sense for a refresh token to passed into
> an introspection request as a refresh token should only be accessible to
> the client and the authorization server (neither of which are intended
> consumers of the introspection endpoints).
>
>
> Many thanks,
> David Skaife
>
> On Fri, Feb 28, 2020 at 9:59 AM Bill Jung  40pingidentity@dmarc.ietf.org> wrote:
>
>> Hello, hopefully I am using the right email address.
>>
>> Simply put, can this spec be enhanced to clarify "Who can use the
>> introspection endpoint for a refresh token? A resource provider or a client
>> app or both?"
>>
>> RFC7662 clearly mentions that the user of introspection endpoint is a
>> 'protected resource' and that makes sense for an access token. If we allow
>> this to client apps, it'll give unnecessary token information to them.
>> However, the spec also mentions that refresh tokens can also be used
>> against the endpoint.
>> In case of refresh tokens, user of the endpoint should be a client app
>> because refresh tokens are used by clients to get another access token.
>> (Cannot imagine how/why a resource server would introspect a refresh token)
>>
>> Is it correct to assume that the endpoint should be allowed to client
>> apps if they want to examine refresh token's expiry time? Then the RFC
>> should clearly mention it.
>>
>> Thanks in advance.
>>
>> **
>> In https://tools..ietf.org/html/rfc7662
>> 
>> In '1.  Introduction' section says,
>>
>>
>>
>> *"This specification defines a protocol that allows authorizedprotected
>> resources to query the authorization server to determinethe set of metadata
>> for a given token that was presented to them byan OAuth 2.0 client."*
>> Above makes clear that user of the endpoint is a "protected resource".
>>
>> And under 'token' in '2.1.  Introspection Request' section says,
>>
>>
>> *"For refresh tokens,this is the "refresh_token" value returned from the
>> token endpointas defined in OAuth 2.0 [RFC6749], Section 5.1."*
>> So looks like a refresh token is allowed for this endpoint.
>>
>>
>> [image: Ping Identity]
>> 
>> Bill Jung
>> Manager, Response Engineering
>> bj...@pingidentity.com
>> w: +1 604.697.7037
>> Connect with us: [image: Glassdoor logo]
>> 
>>  [image:
>> Linked

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Torsten Lodderstedt]

> Am 04.03.2020 um 19:18 schrieb Filip Skokan :
> 
> 
> Sorry, i meant - is top level jti required as well?

I don’t see any use case for it, but that might be due to lack of creativity :-)

> 
> S pozdravem,
> Filip Skokan
> 
> 
>> On Wed, 4 Mar 2020 at 19:15, Filip Skokan  wrote:
>> Torsten, let's make sure we call out the required top level JWT claims - 
>> iss, iat, aud, what else? is top level iat required as well?
>> 
>> S pozdravem,
>> Filip Skokan
>> 
>> 
>>> On Wed, 4 Mar 2020 at 17:19, Torsten Lodderstedt  
>>> wrote:
>>> Hi all, 
>>> 
>>> based on the recent feedback, Vladimir and I propose the following changes 
>>> to draft-ietf-oauth-jwt-introspection-response: 
>>> 
>>> - the token data are encapsulated in a container element “_token_data”
>>> - beyond this, the top-level container only contains meta data pertinent to 
>>> the JWT representing the signed (encrypted) introspection response
>>> - we need to add text to the spec to point out that replay detection must 
>>> be based on the jti in the “_token_data” container not the top level claim
>>> 
>>> That’s example of how it would look like:
>>> 
>>> {
>>>"iss":"https://as.example-bank.com";,
>>>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>>"iat":1532452100,
>>>"_token_data":{
>>>   "active":true,
>>>   "iss":"https://as.example-bank.com";,
>>>   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>>   "jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>>>   "iat":1532452084,
>>>   "exp":1532453100,
>>>   "client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>>>   "cnf":{
>>>  "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>>>   },
>>>   "sub":"123456789087632345678"
>>>}
>>> }
>>> 
>>> The response for inactive tokens would look like this:
>>> 
>>> {
>>>"iss":"https://as.example-bank.com";,
>>>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>>"iat":1532452100,
>>>"_token_data":{
>>>   "active":false
>>>}
>>> }
>>> 
>>> What do you think?
>>> 
>>> best regards,
>>> Torsten. 
>>> 
>>> > On 4. Mar 2020, at 16:37, Justin Richer  wrote:
>>> > 
>>> > +1, this encapsulation is much cleaner.
>>> > 
>>> >> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
>>> >> 
>>> >> Perhaps we should consider leaving the root level JWT claims as-is per 
>>> >> JWT and push the introspection response unmodified as if it was regular 
>>> >> json response to a JWT claim called "introspection". Since regular 
>>> >> introspection uses the same claim names as JWT this would get around all 
>>> >> the conflicts.
>>> >> 
>>> >> Last time i brought it up the authors didn't want to consider it because 
>>> >> of existing implementations.
>>> >> 
>>> >> S pozdravem,
>>> >> Filip Skokan
>>> >> 
>>> >> 
>>> >> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki  wrote:
>>> >> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the 
>>> >> same concerns in this mailing list about 6 months ago (on Sep. 4, 2019). 
>>> >> RFC 8707 didn't exist then, though.
>>> >> 
>>> >> Re: [OAUTH-WG] Question regarding 
>>> >> draft-ietf-oauth-jwt-introspection-response-05
>>> >> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
>>> >> 
>>> >> A JWT puts both (a) information about itself and (b) other data in its 
>>> >> payload part. When the "other data" have the same claim names as are 
>>> >> used to express information about the JWT itself, conflicts happen.
>>> >> 
>>> >> Also, it should be noted that Ben pointed out in other thread that the 
>>> >> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, 
>>> >> which says "jti" is a unique identifier for the access token that MUST 
>>> >> be stable for all introspection calls, contradicts the definition of 
>>> >> "jti", which should be unique for each JWT.
>>> >> 
>>> >> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on 
>>> >> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and 
>>> >> COMMENT)
>>> >> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
>>> >> 
>>> >> draft-ietf-oauth-jwt-introspection-response needs to be modified to 
>>> >> solve the conflicts.
>>> >> 
>>> >> Taka
>>> >> 
>>> >> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki  
>>> >> wrote:
>>> >> Hello,
>>> >> 
>>> >> I'm wondering if the following conflicts in "JWT Response for OAuth 
>>> >> Token Introspection" (draft 8) have already been pointed out.
>>> >> 
>>> >> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an 
>>> >> introspection response hold the values of the 'resource' request 
>>> >> parameters, whereas "JWT Response for OAuth Token Introspection" says 
>>> >> that 'aud' MUST identify the resource server receiving the token 
>>> >> introspection response. The definitions conflict.
>>> >> 
>>> >> RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an 
>>> >> introspection response indicate when the access/refresh token was 
>>> >> issued, whereas "J

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

[Filip Skokan]

I guess what i meant to call out is that while you and the spec says how
omitted fields should be handled, but in the same section earlier it states
that all fields must be included.

S pozdravem,
*Filip Skokan*


On Wed, 4 Mar 2020 at 17:35, Justin Richer  wrote:

> I’m not sure what you’re asking — the text is not left over from anything
> and is intentionally included. That text is saying that if I leave out the
> field then the server treats it just like as if I had sent in a null value.
> So the following are equivalent:
>
> {
>   “client_name”: “foo”,
>   “tos_uri”: null
> }
>
> And
>
> {
>   “client_name”: “foo”,
> }
>
>
> In both cases, it’s a signal that the client is removing the value from
> the “tos_uri” field. It does not mean that the AS leaves the “tos_uri”
> field with the value that it previously was (ie, a PATCH style request).
>
> The AS can reject the update request if it doesn’t want to allow the
> client to blank out that field, for whatever reason.
>
>  — Justin
>
>
> On Mar 4, 2020, at 10:42 AM, Filip Skokan  wrote:
>
> So the following
>
> Omitted fields MUST be treated as null or empty values by the server,
>> indicating the client's request to delete them from the client's
>> registration.
>
>
> Does not mean the server needs to accept requests where fields are
> omitted? Is that a left over from previous drafts then?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 4 Mar 2020 at 16:37, Justin Richer  wrote:
>
>> Your interpretation was our intent with that. It’s a full replace of the
>> object. We had debating having PATCH style semantics, but ultimately
>> decided that that was too complex for the most common update actions that a
>> client would have.
>>
>>  — Justin
>>
>> On Mar 3, 2020, at 8:42 AM, Filip Skokan  wrote:
>>
>> Hello everyone,
>>
>> Section 2.2 of RFC 7592 
>> (Dynamic Client Registration Management Protocol) has the following two
>> statements that oppose one another.
>>
>> This request MUST include all client metadata fields as returned to the
>>> client from a previous registration, read, or update operation.
>>
>>
>> Omitted fields MUST be treated as null or empty values by the server,
>>> indicating the client's request to delete them from the client's
>>> registration.
>>
>>
>> What's the intention here? Should a server be accepting requests that are
>> missing client properties it has either on the record or "resolved" or not?
>>
>> Personally I like to always make sure the client submits everything and
>> to remove properties it must pass null or empty string as the values. That
>> way the request is 100% intentional about the final state of the record it
>> wants to update to.
>>
>> What do you think?
>>
>> Best,
>> *Filip*
>> ___
>> 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

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Filip Skokan]

Sorry, i meant - is top level jti required as well?

S pozdravem,
*Filip Skokan*


On Wed, 4 Mar 2020 at 19:15, Filip Skokan  wrote:

> Torsten, let's make sure we call out the required top level JWT claims -
> iss, iat, aud, what else? is top level iat required as well?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 4 Mar 2020 at 17:19, Torsten Lodderstedt 
> wrote:
>
>> Hi all,
>>
>> based on the recent feedback, Vladimir and I propose the following
>> changes to draft-ietf-oauth-jwt-introspection-response:
>>
>> - the token data are encapsulated in a container element “_token_data”
>> - beyond this, the top-level container only contains meta data pertinent
>> to the JWT representing the signed (encrypted) introspection response
>> - we need to add text to the spec to point out that replay detection must
>> be based on the jti in the “_token_data” container not the top level claim
>>
>> That’s example of how it would look like:
>>
>> {
>>"iss":"https://as.example-bank.com";,
>>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>"iat":1532452100,
>>"_token_data":{
>>   "active":true,
>>   "iss":"https://as.example-bank.com";,
>>   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>   "jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>>   "iat":1532452084,
>>   "exp":1532453100,
>>   "client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>>   "cnf":{
>>  "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>>   },
>>   "sub":"123456789087632345678"
>>}
>> }
>>
>> The response for inactive tokens would look like this:
>>
>> {
>>"iss":"https://as.example-bank.com";,
>>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>"iat":1532452100,
>>"_token_data":{
>>   "active":false
>>}
>> }
>>
>> What do you think?
>>
>> best regards,
>> Torsten.
>>
>> > On 4. Mar 2020, at 16:37, Justin Richer  wrote:
>> >
>> > +1, this encapsulation is much cleaner.
>> >
>> >> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
>> >>
>> >> Perhaps we should consider leaving the root level JWT claims as-is per
>> JWT and push the introspection response unmodified as if it was regular
>> json response to a JWT claim called "introspection". Since regular
>> introspection uses the same claim names as JWT this would get around all
>> the conflicts.
>> >>
>> >> Last time i brought it up the authors didn't want to consider it
>> because of existing implementations.
>> >>
>> >> S pozdravem,
>> >> Filip Skokan
>> >>
>> >>
>> >> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki 
>> wrote:
>> >> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed
>> the same concerns in this mailing list about 6 months ago (on Sep. 4,
>> 2019). RFC 8707 didn't exist then, though.
>> >>
>> >> Re: [OAUTH-WG] Question regarding
>> draft-ietf-oauth-jwt-introspection-response-05
>> >>
>> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
>> >>
>> >> A JWT puts both (a) information about itself and (b) other data in its
>> payload part. When the "other data" have the same claim names as are used
>> to express information about the JWT itself, conflicts happen.
>> >>
>> >> Also, it should be noted that Ben pointed out in other thread that the
>> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which
>> says "jti" is a unique identifier for the access token that MUST be stable
>> for all introspection calls, contradicts the definition of "jti", which
>> should be unique for each JWT.
>> >>
>> >> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
>> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
>> >>
>> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
>> >>
>> >> draft-ietf-oauth-jwt-introspection-response needs to be modified to
>> solve the conflicts.
>> >>
>> >> Taka
>> >>
>> >> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki 
>> wrote:
>> >> Hello,
>> >>
>> >> I'm wondering if the following conflicts in "JWT Response for OAuth
>> Token Introspection" (draft 8) have already been pointed out.
>> >>
>> >> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an
>> introspection response hold the values of the 'resource' request
>> parameters, whereas "JWT Response for OAuth Token Introspection" says that
>> 'aud' MUST identify the resource server receiving the token introspection
>> response. The definitions conflict.
>> >>
>> >> RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an
>> introspection response indicate when the access/refresh token was issued,
>> whereas "JWT Response for OAuth Token Introspection" says that 'iat'
>> indicates when the introspection response in JWT format was issued. The
>> definitions conflict.
>> >>
>> >> Best Regards,
>> >> Takahiko Kawasaki
>> >> Authlete, Inc.
>> >>
>> >>
>> >>
>> >> ___
>> >> OAuth mailing list
>> >> OAuth@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/oauth
>> >

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Filip Skokan]

Torsten, let's make sure we call out the required top level JWT claims -
iss, iat, aud, what else? is top level iat required as well?

S pozdravem,
*Filip Skokan*


On Wed, 4 Mar 2020 at 17:19, Torsten Lodderstedt 
wrote:

> Hi all,
>
> based on the recent feedback, Vladimir and I propose the following changes
> to draft-ietf-oauth-jwt-introspection-response:
>
> - the token data are encapsulated in a container element “_token_data”
> - beyond this, the top-level container only contains meta data pertinent
> to the JWT representing the signed (encrypted) introspection response
> - we need to add text to the spec to point out that replay detection must
> be based on the jti in the “_token_data” container not the top level claim
>
> That’s example of how it would look like:
>
> {
>"iss":"https://as.example-bank.com";,
>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>"iat":1532452100,
>"_token_data":{
>   "active":true,
>   "iss":"https://as.example-bank.com";,
>   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>   "jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>   "iat":1532452084,
>   "exp":1532453100,
>   "client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>   "cnf":{
>  "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>   },
>   "sub":"123456789087632345678"
>}
> }
>
> The response for inactive tokens would look like this:
>
> {
>"iss":"https://as.example-bank.com";,
>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>"iat":1532452100,
>"_token_data":{
>   "active":false
>}
> }
>
> What do you think?
>
> best regards,
> Torsten.
>
> > On 4. Mar 2020, at 16:37, Justin Richer  wrote:
> >
> > +1, this encapsulation is much cleaner.
> >
> >> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
> >>
> >> Perhaps we should consider leaving the root level JWT claims as-is per
> JWT and push the introspection response unmodified as if it was regular
> json response to a JWT claim called "introspection". Since regular
> introspection uses the same claim names as JWT this would get around all
> the conflicts.
> >>
> >> Last time i brought it up the authors didn't want to consider it
> because of existing implementations.
> >>
> >> S pozdravem,
> >> Filip Skokan
> >>
> >>
> >> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki 
> wrote:
> >> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the
> same concerns in this mailing list about 6 months ago (on Sep. 4, 2019).
> RFC 8707 didn't exist then, though.
> >>
> >> Re: [OAUTH-WG] Question regarding
> draft-ietf-oauth-jwt-introspection-response-05
> >>
> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
> >>
> >> A JWT puts both (a) information about itself and (b) other data in its
> payload part. When the "other data" have the same claim names as are used
> to express information about the JWT itself, conflicts happen.
> >>
> >> Also, it should be noted that Ben pointed out in other thread that the
> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which
> says "jti" is a unique identifier for the access token that MUST be stable
> for all introspection calls, contradicts the definition of "jti", which
> should be unique for each JWT.
> >>
> >> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
> >>
> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
> >>
> >> draft-ietf-oauth-jwt-introspection-response needs to be modified to
> solve the conflicts.
> >>
> >> Taka
> >>
> >> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki 
> wrote:
> >> Hello,
> >>
> >> I'm wondering if the following conflicts in "JWT Response for OAuth
> Token Introspection" (draft 8) have already been pointed out.
> >>
> >> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an
> introspection response hold the values of the 'resource' request
> parameters, whereas "JWT Response for OAuth Token Introspection" says that
> 'aud' MUST identify the resource server receiving the token introspection
> response. The definitions conflict.
> >>
> >> RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an
> introspection response indicate when the access/refresh token was issued,
> whereas "JWT Response for OAuth Token Introspection" says that 'iat'
> indicates when the introspection response in JWT format was issued. The
> definitions conflict.
> >>
> >> Best Regards,
> >> Takahiko Kawasaki
> >> Authlete, Inc.
> >>
> >>
> >>
> >> ___
> >> 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 mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/list

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Justin Richer]

Gotcha, thanks. I’d prefer without it, I don’t think the meaning is any more 
“special” than another container field would be. I like this kind of 
encapsulation, though.

And to be honest, I wish we’d done that structure with dynamic registration as 
well. A software statement runs into similar issues but we got lucky that there 
weren’t the same kind of conflicts that we see here.

 — Justin

> On Mar 4, 2020, at 11:49 AM, Torsten Lodderstedt  
> wrote:
> 
> no particular reason, just indicating special meaning. I can live without it.
> 
>> Am 04.03.2020 um 17:29 schrieb Justin Richer :
>> 
>> Why the leading underscore in the name? Why not just “token_data”?
>> 
>> — Justin
>> 
>>> On Mar 4, 2020, at 11:19 AM, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> Hi all, 
>>> 
>>> based on the recent feedback, Vladimir and I propose the following changes 
>>> to draft-ietf-oauth-jwt-introspection-response: 
>>> 
>>> - the token data are encapsulated in a container element “_token_data”
>>> - beyond this, the top-level container only contains meta data pertinent to 
>>> the JWT representing the signed (encrypted) introspection response
>>> - we need to add text to the spec to point out that replay detection must 
>>> be based on the jti in the “_token_data” container not the top level claim
>>> 
>>> That’s example of how it would look like:
>>> 
>>> {
>>> "iss":"https://as.example-bank.com";,
>>> "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>> "iat":1532452100,
>>> "_token_data":{
>>>"active":true,
>>>"iss":"https://as.example-bank.com";,
>>>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>>"jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>>>"iat":1532452084,
>>>"exp":1532453100,
>>>"client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>>>"cnf":{
>>>   "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>>>},
>>>"sub":"123456789087632345678"
>>> }
>>> }
>>> 
>>> The response for inactive tokens would look like this:
>>> 
>>> {
>>> "iss":"https://as.example-bank.com";,
>>> "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>> "iat":1532452100,
>>> "_token_data":{
>>>"active":false
>>> }
>>> }
>>> 
>>> What do you think?
>>> 
>>> best regards,
>>> Torsten. 
>>> 
> On 4. Mar 2020, at 16:37, Justin Richer  wrote:
 
 +1, this encapsulation is much cleaner.
 
> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
> 
> Perhaps we should consider leaving the root level JWT claims as-is per 
> JWT and push the introspection response unmodified as if it was regular 
> json response to a JWT claim called "introspection". Since regular 
> introspection uses the same claim names as JWT this would get around all 
> the conflicts.
> 
> Last time i brought it up the authors didn't want to consider it because 
> of existing implementations.
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki  wrote:
> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the 
> same concerns in this mailing list about 6 months ago (on Sep. 4, 2019). 
> RFC 8707 didn't exist then, though.
> 
> Re: [OAUTH-WG] Question regarding 
> draft-ietf-oauth-jwt-introspection-response-05
> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
> 
> A JWT puts both (a) information about itself and (b) other data in its 
> payload part. When the "other data" have the same claim names as are used 
> to express information about the JWT itself, conflicts happen.
> 
> Also, it should be noted that Ben pointed out in other thread that the 
> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, 
> which says "jti" is a unique identifier for the access token that MUST be 
> stable for all introspection calls, contradicts the definition of "jti", 
> which should be unique for each JWT.
> 
> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on 
> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
> 
> draft-ietf-oauth-jwt-introspection-response needs to be modified to solve 
> the conflicts.
> 
> Taka
> 
> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki  
> wrote:
> Hello,
> 
> I'm wondering if the following conflicts in "JWT Response for OAuth Token 
> Introspection" (draft 8) have already been pointed out.
> 
> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an 
> introspection response hold the values of the 'resource' request 
> parameters, whereas "JWT Response for OAuth Token Introspection" says 
> that 'aud' MUST identify the resource server receiving the token 
> introspection response. The definitions conflict.
> 
> RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an 
> in

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Torsten Lodderstedt]

no particular reason, just indicating special meaning. I can live without it..

> Am 04.03.2020 um 17:29 schrieb Justin Richer :
> 
> Why the leading underscore in the name? Why not just “token_data”?
> 
> — Justin
> 
>> On Mar 4, 2020, at 11:19 AM, Torsten Lodderstedt  
>> wrote:
>> 
>> Hi all, 
>> 
>> based on the recent feedback, Vladimir and I propose the following changes 
>> to draft-ietf-oauth-jwt-introspection-response: 
>> 
>> - the token data are encapsulated in a container element “_token_data”
>> - beyond this, the top-level container only contains meta data pertinent to 
>> the JWT representing the signed (encrypted) introspection response
>> - we need to add text to the spec to point out that replay detection must be 
>> based on the jti in the “_token_data” container not the top level claim
>> 
>> That’s example of how it would look like:
>> 
>> {
>>  "iss":"https://as.example-bank.com";,
>>  "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>  "iat":1532452100,
>>  "_token_data":{
>> "active":true,
>> "iss":"https://as.example-bank.com";,
>> "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>> "jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>> "iat":1532452084,
>> "exp":1532453100,
>> "client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>> "cnf":{
>>"x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>> },
>> "sub":"123456789087632345678"
>>  }
>> }
>> 
>> The response for inactive tokens would look like this:
>> 
>> {
>>  "iss":"https://as.example-bank.com";,
>>  "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>  "iat":1532452100,
>>  "_token_data":{
>> "active":false
>>  }
>> }
>> 
>> What do you think?
>> 
>> best regards,
>> Torsten. 
>> 
 On 4. Mar 2020, at 16:37, Justin Richer  wrote:
>>> 
>>> +1, this encapsulation is much cleaner.
>>> 
 On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
 
 Perhaps we should consider leaving the root level JWT claims as-is per JWT 
 and push the introspection response unmodified as if it was regular json 
 response to a JWT claim called "introspection". Since regular 
 introspection uses the same claim names as JWT this would get around all 
 the conflicts.
 
 Last time i brought it up the authors didn't want to consider it because 
 of existing implementations.
 
 S pozdravem,
 Filip Skokan
 
 
 On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki  wrote:
 Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the 
 same concerns in this mailing list about 6 months ago (on Sep. 4, 2019). 
 RFC 8707 didn't exist then, though.
 
 Re: [OAUTH-WG] Question regarding 
 draft-ietf-oauth-jwt-introspection-response-05
 https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
 
 A JWT puts both (a) information about itself and (b) other data in its 
 payload part. When the "other data" have the same claim names as are used 
 to express information about the JWT itself, conflicts happen.
 
 Also, it should be noted that Ben pointed out in other thread that the 
 requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, 
 which says "jti" is a unique identifier for the access token that MUST be 
 stable for all introspection calls, contradicts the definition of "jti", 
 which should be unique for each JWT.
 
 Re: [OAUTH-WG] Benjamin Kaduk's Discuss on 
 draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
 https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
 
 draft-ietf-oauth-jwt-introspection-response needs to be modified to solve 
 the conflicts.
 
 Taka
 
 On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki  
 wrote:
 Hello,
 
 I'm wondering if the following conflicts in "JWT Response for OAuth Token 
 Introspection" (draft 8) have already been pointed out.
 
 RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an 
 introspection response hold the values of the 'resource' request 
 parameters, whereas "JWT Response for OAuth Token Introspection" says that 
 'aud' MUST identify the resource server receiving the token introspection 
 response. The definitions conflict.
 
 RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an 
 introspection response indicate when the access/refresh token was issued, 
 whereas "JWT Response for OAuth Token Introspection" says that 'iat' 
 indicates when the introspection response in JWT format was issued. The 
 definitions conflict.
 
 Best Regards,
 Takahiko Kawasaki
 Authlete, Inc.
 
 
 
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
 ___
 OAuth mailing list
>

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

[Justin Richer]

Again — isn’t this just the client credentials grant but with extra steps?

 — Justin

> On Mar 1, 2020, at 11:33 AM, Phillip Hunt  wrote:
> 
> Why not just require service accounts to use mutually acceptable http method 
> of authentication?  Eg instead id/password, service acnt client could use 
> mtls auth or http basic or some other method.  
> 
> AFAIK this is already widely done. 
> 
> Is there so much interop value that specifying only the weakest form of 
> authentication is warranted?
> 
> Phil
> 
>> On Mar 1, 2020, at 4:09 AM, Dominick Baier  wrote:
>> 
>> 
>> 2) write an OAuth 2.1 extension for service account grants. (the grant type 
>> could continue to be "password", but now clearly in the context of a service 
>> account in a different document)
>> 
>> IMHO - if such a thing gets defined, it should be a separate document. Keep 
>> 2.1 as simple as possible.
>> 
>> ———
>> Dominick Baier
>> 
>> On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com 
>> ) wrote:
>> 
>>> It looks like there is consensus to remove ROPC for a user -- but that the 
>>> password grant is not a bad practice for service accounts. That leads to 
>>> providing clarity on service accounts.
>>> 
>>> 1) add service account grant to the OAuth 2.1 document
>>> 
>>> 2) write an OAuth 2.1 extension for service account grants. (the grant type 
>>> could continue to be "password", but now clearly in the context of a 
>>> service account in a different document)
>>> 
>>> With the goal of OAuth 2..1 being a capture of all the best practices, (2) 
>>> makes more sense as it could discuss all aspects of service accounts 
>>> including mapping a client to a service account. 
>>> 
>>> What do others think?
>>> 
>>> 
>>> ᐧ
>>> 
>>> On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura >> > wrote:
>>> Let us do it then and deprecate ROPC. 
>>> There definitely are use-cases that need this pattern around me as well, 
>>> but we are using JWT bearer grant instead. Standardizing the behavior is 
>>> good. I am fine with new service_account grant type as well, btw. 
>>> 
>>> Nat
>>> 2020年2月25日 20:41 +0900、Neil Madden >> > のメール:
 I’d be open to defining a new service_account grant type and 
 removing/deprecating the ROPC grant. I’d also be happy if we just said 
 that service account flows should use the JWT bearer grant, and we 
 document the best practices around that and encourage client libs to 
 implement support for it.
 
 Should there be a dedicated draft for best practices for 
 service-to-service usage?
 
 — Neil
 
> On 25 Feb 2020, at 00:13, Aaron Parecki  > wrote:
> 
> I think we might be going about this discussion the wrong way.
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  > wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  > wrote:
> I’m not really sure the WG should be telling people what they “ought to 
> be doing” unless we have concrete security or interoperability reasons 
> for doing so.
> 
> I 100% agree that the job of a standard is not to tell people "what they 
> ought to be doing". Instead, a standard is more about documenting the 
> current state of the art as deployed in existing implementations.
> 
> With that in mind, I think that leaves us with two concrete problems with 
> the password grant:
> 
> 1) The actual problem with the password grant is end users entering 
> passwords in applications, which the group (mostly) agrees on
> 2) People are re-appropriating the password grant for things like service 
> accounts or backends that are inflexible, not actually using it for end 
> user credentials
> 
> So it seems like there's actually something missing from OAuth which is 
> leading people to find the password grant and use that because it's the 
> only thing that most closely fits their existing model. It seems like 
> we'd be better off defining a new extension that captures the use case 
> people are actually doing, instead of encouraging the continuing use of 
> the password grant for this purpose.
> 
> 
> Aaron Parecki
> aaronparecki.com 
> @aaronpk
> 
> 
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  > wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  > wrote:
> I’m not really sure the WG should be telling people what they “ought to 
> be doing” unless we have concrete security or interoperability reasons 
> for doing so.
>

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

[Filip Skokan]

Got it, thanks!

Best,
Filip


On Wed, 4 Mar 2020 at 17:35, Justin Richer  wrote:

> I’m not sure what you’re asking — the text is not left over from anything
> and is intentionally included. That text is saying that if I leave out the
> field then the server treats it just like as if I had sent in a null value.
> So the following are equivalent:
>
> {
>   “client_name”: “foo”,
>   “tos_uri”: null
> }
>
> And
>
> {
>   “client_name”: “foo”,
> }
>
>
> In both cases, it’s a signal that the client is removing the value from
> the “tos_uri” field. It does not mean that the AS leaves the “tos_uri”
> field with the value that it previously was (ie, a PATCH style request).
>
> The AS can reject the update request if it doesn’t want to allow the
> client to blank out that field, for whatever reason.
>
>  — Justin
>
>
> On Mar 4, 2020, at 10:42 AM, Filip Skokan  wrote:
>
> So the following
>
> Omitted fields MUST be treated as null or empty values by the server,
>> indicating the client's request to delete them from the client's
>> registration.
>
>
> Does not mean the server needs to accept requests where fields are
> omitted? Is that a left over from previous drafts then?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 4 Mar 2020 at 16:37, Justin Richer  wrote:
>
>> Your interpretation was our intent with that. It’s a full replace of the
>> object. We had debating having PATCH style semantics, but ultimately
>> decided that that was too complex for the most common update actions that a
>> client would have.
>>
>>  — Justin
>>
>> On Mar 3, 2020, at 8:42 AM, Filip Skokan  wrote:
>>
>> Hello everyone,
>>
>> Section 2.2 of RFC 7592 
>> (Dynamic Client Registration Management Protocol) has the following two
>> statements that oppose one another.
>>
>> This request MUST include all client metadata fields as returned to the
>>> client from a previous registration, read, or update operation.
>>
>>
>> Omitted fields MUST be treated as null or empty values by the server,
>>> indicating the client's request to delete them from the client's
>>> registration.
>>
>>
>> What's the intention here? Should a server be accepting requests that are
>> missing client properties it has either on the record or "resolved" or not?
>>
>> Personally I like to always make sure the client submits everything and
>> to remove properties it must pass null or empty string as the values. That
>> way the request is 100% intentional about the final state of the record it
>> wants to update to.
>>
>> What do you think?
>>
>> Best,
>> *Filip*
>> ___
>> 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

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

[Justin Richer]

I’m not sure what you’re asking — the text is not left over from anything and 
is intentionally included. That text is saying that if I leave out the field 
then the server treats it just like as if I had sent in a null value. So the 
following are equivalent:

{
  “client_name”: “foo”,
  “tos_uri”: null
}

And 

{
  “client_name”: “foo”,
}


In both cases, it’s a signal that the client is removing the value from the 
“tos_uri” field. It does not mean that the AS leaves the “tos_uri” field with 
the value that it previously was (ie, a PATCH style request). 

The AS can reject the update request if it doesn’t want to allow the client to 
blank out that field, for whatever reason. 

 — Justin


> On Mar 4, 2020, at 10:42 AM, Filip Skokan  wrote:
> 
> So the following
> 
> Omitted fields MUST be treated as null or empty values by the server, 
> indicating the client's request to delete them from the client's registration.
> 
> Does not mean the server needs to accept requests where fields are omitted? 
> Is that a left over from previous drafts then?
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Wed, 4 Mar 2020 at 16:37, Justin Richer  > wrote:
> Your interpretation was our intent with that. It’s a full replace of the 
> object. We had debating having PATCH style semantics, but ultimately decided 
> that that was too complex for the most common update actions that a client 
> would have.
> 
>  — Justin
> 
>> On Mar 3, 2020, at 8:42 AM, Filip Skokan > > wrote:
>> 
>> Hello everyone,
>> 
>> Section 2.2 of RFC 7592  
>> (Dynamic Client Registration Management Protocol) has the following two 
>> statements that oppose one another.
>> 
>> This request MUST include all client metadata fields as returned to the 
>> client from a previous registration, read, or update operation.
>> 
>> Omitted fields MUST be treated as null or empty values by the server, 
>> indicating the client's request to delete them from the client's 
>> registration.
>> 
>> What's the intention here? Should a server be accepting requests that are 
>> missing client properties it has either on the record or "resolved" or not?
>> 
>> Personally I like to always make sure the client submits everything and to 
>> remove properties it must pass null or empty string as the values. That way 
>> the request is 100% intentional about the final state of the record it wants 
>> to update to.
>> 
>> What do you think?
>> 
>> Best,
>> Filip
>> ___
>> 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

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Justin Richer]

Why the leading underscore in the name? Why not just “token_data”?

 — Justin

> On Mar 4, 2020, at 11:19 AM, Torsten Lodderstedt  
> wrote:
> 
> Hi all, 
> 
> based on the recent feedback, Vladimir and I propose the following changes to 
> draft-ietf-oauth-jwt-introspection-response: 
> 
> - the token data are encapsulated in a container element “_token_data”
> - beyond this, the top-level container only contains meta data pertinent to 
> the JWT representing the signed (encrypted) introspection response
> - we need to add text to the spec to point out that replay detection must be 
> based on the jti in the “_token_data” container not the top level claim
> 
> That’s example of how it would look like:
> 
> {
>   "iss":"https://as.example-bank.com";,
>   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>   "iat":1532452100,
>   "_token_data":{
>  "active":true,
>  "iss":"https://as.example-bank.com";,
>  "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>  "jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>  "iat":1532452084,
>  "exp":1532453100,
>  "client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>  "cnf":{
> "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>  },
>  "sub":"123456789087632345678"
>   }
> }
> 
> The response for inactive tokens would look like this:
> 
> {
>   "iss":"https://as.example-bank.com";,
>   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>   "iat":1532452100,
>   "_token_data":{
>  "active":false
>   }
> }
> 
> What do you think?
> 
> best regards,
> Torsten. 
> 
>> On 4. Mar 2020, at 16:37, Justin Richer  wrote:
>> 
>> +1, this encapsulation is much cleaner.
>> 
>>> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
>>> 
>>> Perhaps we should consider leaving the root level JWT claims as-is per JWT 
>>> and push the introspection response unmodified as if it was regular json 
>>> response to a JWT claim called "introspection". Since regular introspection 
>>> uses the same claim names as JWT this would get around all the conflicts.
>>> 
>>> Last time i brought it up the authors didn't want to consider it because of 
>>> existing implementations.
>>> 
>>> S pozdravem,
>>> Filip Skokan
>>> 
>>> 
>>> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki  wrote:
>>> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the 
>>> same concerns in this mailing list about 6 months ago (on Sep. 4, 2019). 
>>> RFC 8707 didn't exist then, though.
>>> 
>>> Re: [OAUTH-WG] Question regarding 
>>> draft-ietf-oauth-jwt-introspection-response-05
>>> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
>>> 
>>> A JWT puts both (a) information about itself and (b) other data in its 
>>> payload part. When the "other data" have the same claim names as are used 
>>> to express information about the JWT itself, conflicts happen.
>>> 
>>> Also, it should be noted that Ben pointed out in other thread that the 
>>> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which 
>>> says "jti" is a unique identifier for the access token that MUST be stable 
>>> for all introspection calls, contradicts the definition of "jti", which 
>>> should be unique for each JWT.
>>> 
>>> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on 
>>> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
>>> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
>>> 
>>> draft-ietf-oauth-jwt-introspection-response needs to be modified to solve 
>>> the conflicts.
>>> 
>>> Taka
>>> 
>>> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki  wrote:
>>> Hello,
>>> 
>>> I'm wondering if the following conflicts in "JWT Response for OAuth Token 
>>> Introspection" (draft 8) have already been pointed out.
>>> 
>>> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an 
>>> introspection response hold the values of the 'resource' request 
>>> parameters, whereas "JWT Response for OAuth Token Introspection" says that 
>>> 'aud' MUST identify the resource server receiving the token introspection 
>>> response. The definitions conflict.
>>> 
>>> RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an 
>>> introspection response indicate when the access/refresh token was issued, 
>>> whereas "JWT Response for OAuth Token Introspection" says that 'iat' 
>>> indicates when the introspection response in JWT format was issued. The 
>>> definitions conflict.
>>> 
>>> Best Regards,
>>> Takahiko Kawasaki
>>> Authlete, Inc.
>>> 
>>> 
>>> 
>>> ___
>>> 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 mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 

__

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Torsten Lodderstedt]

Hi all, 

based on the recent feedback, Vladimir and I propose the following changes to 
draft-ietf-oauth-jwt-introspection-response: 

- the token data are encapsulated in a container element “_token_data”
- beyond this, the top-level container only contains meta data pertinent to the 
JWT representing the signed (encrypted) introspection response
- we need to add text to the spec to point out that replay detection must be 
based on the jti in the “_token_data” container not the top level claim

That’s example of how it would look like:

{
   "iss":"https://as.example-bank.com";,
   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
   "iat":1532452100,
   "_token_data":{
  "active":true,
  "iss":"https://as.example-bank.com";,
  "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
  "jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
  "iat":1532452084,
  "exp":1532453100,
  "client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
  "cnf":{
 "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
  },
  "sub":"123456789087632345678"
   }
}

The response for inactive tokens would look like this:

{
   "iss":"https://as.example-bank.com";,
   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
   "iat":1532452100,
   "_token_data":{
  "active":false
   }
}

What do you think?

best regards,
Torsten. 

> On 4. Mar 2020, at 16:37, Justin Richer  wrote:
> 
> +1, this encapsulation is much cleaner.
> 
>> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
>> 
>> Perhaps we should consider leaving the root level JWT claims as-is per JWT 
>> and push the introspection response unmodified as if it was regular json 
>> response to a JWT claim called "introspection". Since regular introspection 
>> uses the same claim names as JWT this would get around all the conflicts.
>> 
>> Last time i brought it up the authors didn't want to consider it because of 
>> existing implementations.
>> 
>> S pozdravem,
>> Filip Skokan
>> 
>> 
>> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki  wrote:
>> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the same 
>> concerns in this mailing list about 6 months ago (on Sep. 4, 2019). RFC 8707 
>> didn't exist then, though.
>> 
>> Re: [OAUTH-WG] Question regarding 
>> draft-ietf-oauth-jwt-introspection-response-05
>> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
>> 
>> A JWT puts both (a) information about itself and (b) other data in its 
>> payload part. When the "other data" have the same claim names as are used to 
>> express information about the JWT itself, conflicts happen.
>> 
>> Also, it should be noted that Ben pointed out in other thread that the 
>> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which 
>> says "jti" is a unique identifier for the access token that MUST be stable 
>> for all introspection calls, contradicts the definition of "jti", which 
>> should be unique for each JWT.
>> 
>> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on 
>> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
>> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
>> 
>> draft-ietf-oauth-jwt-introspection-response needs to be modified to solve 
>> the conflicts.
>> 
>> Taka
>> 
>> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki  wrote:
>> Hello,
>> 
>> I'm wondering if the following conflicts in "JWT Response for OAuth Token 
>> Introspection" (draft 8) have already been pointed out.
>> 
>> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an 
>> introspection response hold the values of the 'resource' request parameters, 
>> whereas "JWT Response for OAuth Token Introspection" says that 'aud' MUST 
>> identify the resource server receiving the token introspection response. The 
>> definitions conflict.
>> 
>> RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an 
>> introspection response indicate when the access/refresh token was issued, 
>> whereas "JWT Response for OAuth Token Introspection" says that 'iat' 
>> indicates when the introspection response in JWT format was issued. The 
>> definitions conflict.
>> 
>> Best Regards,
>> Takahiko Kawasaki
>> Authlete, Inc.
>> 
>> 
>> 
>> ___
>> 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 mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

[Filip Skokan]

So the following

Omitted fields MUST be treated as null or empty values by the server,
> indicating the client's request to delete them from the client's
> registration.


Does not mean the server needs to accept requests where fields are omitted?
Is that a left over from previous drafts then?

S pozdravem,
*Filip Skokan*


On Wed, 4 Mar 2020 at 16:37, Justin Richer  wrote:

> Your interpretation was our intent with that. It’s a full replace of the
> object. We had debating having PATCH style semantics, but ultimately
> decided that that was too complex for the most common update actions that a
> client would have.
>
>  — Justin
>
> On Mar 3, 2020, at 8:42 AM, Filip Skokan  wrote:
>
> Hello everyone,
>
> Section 2.2 of RFC 7592 
> (Dynamic Client Registration Management Protocol) has the following two
> statements that oppose one another.
>
> This request MUST include all client metadata fields as returned to the
>> client from a previous registration, read, or update operation.
>
>
> Omitted fields MUST be treated as null or empty values by the server,
>> indicating the client's request to delete them from the client's
>> registration.
>
>
> What's the intention here? Should a server be accepting requests that are
> missing client properties it has either on the record or "resolved" or not?
>
> Personally I like to always make sure the client submits everything and to
> remove properties it must pass null or empty string as the values. That way
> the request is 100% intentional about the final state of the record it
> wants to update to.
>
> What do you think?
>
> Best,
> *Filip*
> ___
> 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

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Justin Richer]

+1, this encapsulation is much cleaner.

> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
> 
> Perhaps we should consider leaving the root level JWT claims as-is per JWT 
> and push the introspection response unmodified as if it was regular json 
> response to a JWT claim called "introspection". Since regular introspection 
> uses the same claim names as JWT this would get around all the conflicts.
> 
> Last time i brought it up the authors didn't want to consider it because of 
> existing implementations.
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki  > wrote:
> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the same 
> concerns in this mailing list about 6 months ago (on Sep. 4, 2019). RFC 8707 
> didn't exist then, though.
> 
> Re: [OAUTH-WG] Question regarding 
> draft-ietf-oauth-jwt-introspection-response-05
> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/ 
> 
> 
> A JWT puts both (a) information about itself and (b) other data in its 
> payload part. When the "other data" have the same claim names as are used to 
> express information about the JWT itself, conflicts happen.
> 
> Also, it should be noted that Ben pointed out in other thread that the 
> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which 
> says "jti" is a unique identifier for the access token that MUST be stable 
> for all introspection calls, contradicts the definition of "jti", which 
> should be unique for each JWT.
> 
> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on 
> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/ 
> 
> 
> draft-ietf-oauth-jwt-introspection-response needs to be modified to solve the 
> conflicts.
> 
> Taka
> 
> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki  > wrote:
> Hello,
> 
> I'm wondering if the following conflicts in "JWT Response for OAuth Token 
> Introspection" (draft 8 
> ) 
> have already been pointed out.
> 
> RFC 8707  (Resource Indicators for OAuth 
> 2.0) requires that 'aud' in an introspection response hold the values of the 
> 'resource' request parameters, whereas "JWT Response for OAuth Token 
> Introspection" says that 'aud' MUST identify the resource server receiving 
> the token introspection response. The definitions conflict.
> 
> RFC 7662  (OAuth 2.0 Token 
> Introspection) requires that 'iat' in an introspection response indicate when 
> the access/refresh token was issued, whereas "JWT Response for OAuth Token 
> Introspection" says that 'iat' indicates when the introspection response in 
> JWT format was issued. The definitions conflict.
> 
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
> 
> 
> 
> ___
> 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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

[Justin Richer]

Your interpretation was our intent with that. It’s a full replace of the 
object. We had debating having PATCH style semantics, but ultimately decided 
that that was too complex for the most common update actions that a client 
would have.

 — Justin

> On Mar 3, 2020, at 8:42 AM, Filip Skokan  wrote:
> 
> Hello everyone,
> 
> Section 2.2 of RFC 7592  
> (Dynamic Client Registration Management Protocol) has the following two 
> statements that oppose one another.
> 
> This request MUST include all client metadata fields as returned to the 
> client from a previous registration, read, or update operation.
> 
> Omitted fields MUST be treated as null or empty values by the server, 
> indicating the client's request to delete them from the client's registration.
> 
> What's the intention here? Should a server be accepting requests that are 
> missing client properties it has either on the record or "resolved" or not?
> 
> Personally I like to always make sure the client submits everything and to 
> remove properties it must pass null or empty string as the values. That way 
> the request is 100% intentional about the final state of the record it wants 
> to update to.
> 
> What do you think?
> 
> Best,
> Filip
> ___
> 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

Re: [OAUTH-WG] OAuth Topics for Vancouver

[Brian Campbell]

Thanks Rifaat,
I'd like to request some time on the agenda to discuss general PoP ideas,
issues, direction, etc..


On Mon, Jan 20, 2020 at 8:33 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Please, let us know if you have any topics that you would like to present
> and discuss in Vancouver.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth