Re: [OAUTH-WG] Token Revocation error codes

[George Fletcher]

As Justin pointed out earlier in the thread, if the value `token` is 
clearly not a valid token, then returning an invalid_request response is 
fine. The key is if the value provided for the token parameter is a 
token, then the API MUST NOT leak whether the token was valid or not.


Is this not sufficient?

On 1/26/22 3:01 PM, Sergey Ponomarev wrote:

Thank you, Waren,

Sorry that was misleading, I meant literally the 'null'  as a string 
which may be because of a bug in the client.

That was an example taken from Thomas Broyer letter:
> For months, my AS received requests with token=Array, and now 
receives requests with token=null. Those are clearly bugs in the 
client code, and because I return a 200 OK, the developers aren't 
aware of it.


If you are interested here is the entire thread:
https://mailarchive.ietf.org/arch/msg/oauth/w68pbTcp2jjk4tzldnS0gOS127Q/

In an ideal world the AS may store even revoked tokens (or JWT kid) 
and clearly return some error in case of unknown token. At least for a 
day, for example. But at least it on a spec level there must be few 
words added into "Security Considerations" section




On Wed, 26 Jan 2022 at 20:13, Warren Parad  wrote:

According to RFC7009, I don't see anywhere which says you have to
return a 200 for token=null. I interpret it as you return a 200,
if the token passed would never have been accepted as a valid
token. *Null* isn't an invalid token, it is an invalid value for
the *token* parameter which is required.

   token   REQUIRED. The token that the client wants to get
revoked.


So the correct response is either an error immediately (returning
a 4XX), or feel free to return the 200 and then the AS should
redirect the user to a verified location with the *error *and
*error_description* query parameters.

I do see some gray area for what to do with real invalid tokens,
i.e. the token signature is invalid. So some clarity on the
definition of *invalid. *Since the spec talks about invalidation
lots of times we should interpret it to mean *a token that has
already been invalidated.* And I would interpret all other tokens
as justifications for returning a 4XX status code.



Warren Parad

Founder, CTO

Secure your user data with IAM authorization as a service.
Implement Authress .


On Wed, Jan 26, 2022 at 6:44 PM Sergey Ponomarev
 wrote:

Hi and sorry for raising the four years old topic.

As a recup I reported a SECURITY VULNERABILITY on OAuth 2
specification level. It's minor (I hope) but still seen in the
real
world AS implementation.
In short, to logout a user the revocation endpoint is called
with the
user's token. And by a the RFC7009 the AS must always return
200 Ok
status code even if the token is invalid:

> The authorization server responds with HTTP status code 200
if the token has been revoked successfully or if the client
submitted an invalid token.
> Note: invalid tokens do not cause an error response since
the client cannot handle such an error in a reasonable way. 
Moreover, the purpose of the revocation request, invalidating
the particular token, is already achieved.

So if a client just made an incorrect call e.g. token=null then it
will anyway receive a 200 OK and the user will think that
logout was
successful and a session closed. But internally the token may be
stored in many places and even shared  between
microservices/UI and
other parties and it will remain still working.

Can anybody take some actions and at least make some errata to
the spec?

P.S. adding to CC authors of the spec

On Tue, 22 May 2018 at 20:29, Sergey Ponomarev
 wrote:
>
> What is also should be discussed and specified is revoking
of expired token. For example in Keycloak you can invalidate a
session by expired token:
>>
>> It should be possible to logout a session with a token that
is expired. This is to make sure that a user can invalidate a
session if there's a suspicion that the refresh/offline token
has been leaked. In such a case it could be that the real user
has an expired refresh token while an attacker has been able
to refresh the token and obtain a new not expired refresh token.
>
>
> KEYCLOAK-3302
>
> Think this is doubtful but makes sense.
>
> To summarize: we have to create some threat model with
description of possible use cases.
>
>
> On Tue, 22 May 2018 at 18:18, Sergey Ponomarev
 wrote:
>>
>> From OAuth perspective we can't say that the token should
have some structure: they can 

Re: [OAUTH-WG] Token Revocation error codes

[Sergey Ponomarev]

Thank you, Waren,

Sorry that was misleading, I meant literally the 'null'  as a string which
may be because of a bug in the client.
That was an example taken from Thomas Broyer letter:
> For months, my AS received requests with token=Array, and now receives
requests with token=null. Those are clearly bugs in the client code, and
because I return a 200 OK, the developers aren't aware of it.

If you are interested here is the entire thread:
https://mailarchive.ietf.org/arch/msg/oauth/w68pbTcp2jjk4tzldnS0gOS127Q/

In an ideal world the AS may store even revoked tokens (or JWT kid) and
clearly return some error in case of unknown token. At least for a day, for
example. But at least it on a spec level there must be few words added into
"Security Considerations" section



On Wed, 26 Jan 2022 at 20:13, Warren Parad  wrote:

> According to RFC7009, I don't see anywhere which says you have to return a
> 200 for token=null. I interpret it as you return a 200, if the token passed
> would never have been accepted as a valid token. *Null* isn't an invalid
> token, it is an invalid value for the *token* parameter which is required.
>
>token   REQUIRED.  The token that the client wants to get revoked.
>
>
> So the correct response is either an error immediately (returning a 4XX),
> or feel free to return the 200 and then the AS should redirect the user to
> a verified location with the *error *and *error_description* query
> parameters.
>
> I do see some gray area for what to do with real invalid tokens, i.e. the
> token signature is invalid. So some clarity on the definition of *invalid.
> *Since the spec talks about invalidation lots of times we should
> interpret it to mean *a token that has already been invalidated.* And I
> would interpret all other tokens as justifications for returning a 4XX
> status code.
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Wed, Jan 26, 2022 at 6:44 PM Sergey Ponomarev 
> wrote:
>
>> Hi and sorry for raising the four years old topic.
>>
>> As a recup I reported a SECURITY VULNERABILITY on OAuth 2
>> specification level. It's minor (I hope) but still seen in the real
>> world AS implementation.
>> In short, to logout a user the revocation endpoint is called with the
>> user's token. And by a the RFC7009 the AS must always return 200 Ok
>> status code even if the token is invalid:
>>
>> > The authorization server responds with HTTP status code 200 if the
>> token has been revoked successfully or if the client submitted an invalid
>> token.
>> > Note: invalid tokens do not cause an error response since the client
>> cannot handle such an error in a reasonable way.  Moreover, the purpose of
>> the revocation request, invalidating the particular token, is already
>> achieved.
>>
>> So if a client just made an incorrect call e.g. token=null then it
>> will anyway receive a 200 OK and the user will think that logout was
>> successful and a session closed. But internally the token may be
>> stored in many places and even shared  between microservices/UI and
>> other parties and it will remain still working.
>>
>> Can anybody take some actions and at least make some errata to the spec?
>>
>> P.S. adding to CC authors of the spec
>>
>> On Tue, 22 May 2018 at 20:29, Sergey Ponomarev  wrote:
>> >
>> > What is also should be discussed and specified is revoking of expired
>> token. For example in Keycloak you can invalidate a session by expired
>> token:
>> >>
>> >> It should be possible to logout a session with a token that is
>> expired. This is to make sure that a user can invalidate a session if
>> there's a suspicion that the refresh/offline token has been leaked. In such
>> a case it could be that the real user has an expired refresh token while an
>> attacker has been able to refresh the token and obtain a new not expired
>> refresh token.
>> >
>> >
>> > KEYCLOAK-3302
>> >
>> > Think this is doubtful but makes sense.
>> >
>> > To summarize: we have to create some threat model with description of
>> possible use cases.
>> >
>> >
>> > On Tue, 22 May 2018 at 18:18, Sergey Ponomarev 
>> wrote:
>> >>
>> >> From OAuth perspective we can't say that the token should have some
>> structure: they can be any random value in case of reference (opaque)
>> tokens. But the Google's OAuth Server responds in this case with 400 error
>> "invalid_token".
>> >> The same can be used for JWTs with invalid sign or issuer.
>> >> So it would be better if specification allow OAuth servers to respond
>> with this error code if it clearly know that token was invalid by format.
>> >>
>> >> On Tue, 22 May 2018 at 17:51, Thomas Broyer 
>> wrote:
>> >>>
>> >>> IFF the server processes it!
>> >>> RFC 7009 says “An authorization server MAY ignore this parameter,
>> particularly if it is able to detect the token type automatically.” which
>> BTW is exactly my case.
>> >>>
>> >>> For months, my AS received requests with 

[OAUTH-WG] oauth - Update to a Meeting Session Request for IETF 113

[IETF Meeting Session Request Tool]

An update to a meeting session request has just been submitted by Rifaat 
Shekh-Yusef, a Chair of the oauth working group.


-
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Rifaat Shekh-Yusef


Number of Sessions: 2
Length of Session(s): 2 Hours, 2 Hours
Number of Attendees: 50
Conflicts to Avoid: 

   


People who must be present:
  Roman Danyliw
  Hannes Tschofenig
  Rifaat Shekh-Yusef

Resources Requested:

Special Requests:
  If it is possible, avoid Friday
-


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

Re: [OAUTH-WG] Token Revocation error codes

[Warren Parad]

According to RFC7009, I don't see anywhere which says you have to return a
200 for token=null. I interpret it as you return a 200, if the token passed
would never have been accepted as a valid token. *Null* isn't an invalid
token, it is an invalid value for the *token* parameter which is required.

   token   REQUIRED.  The token that the client wants to get revoked.


So the correct response is either an error immediately (returning a 4XX),
or feel free to return the 200 and then the AS should redirect the user to
a verified location with the *error *and *error_description* query
parameters.

I do see some gray area for what to do with real invalid tokens, i.e. the
token signature is invalid. So some clarity on the definition of
*invalid. *Since
the spec talks about invalidation lots of times we should interpret it to
mean *a token that has already been invalidated.* And I would interpret all
other tokens as justifications for returning a 4XX status code.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Jan 26, 2022 at 6:44 PM Sergey Ponomarev  wrote:

> Hi and sorry for raising the four years old topic.
>
> As a recup I reported a SECURITY VULNERABILITY on OAuth 2
> specification level. It's minor (I hope) but still seen in the real
> world AS implementation.
> In short, to logout a user the revocation endpoint is called with the
> user's token. And by a the RFC7009 the AS must always return 200 Ok
> status code even if the token is invalid:
>
> > The authorization server responds with HTTP status code 200 if the token
> has been revoked successfully or if the client submitted an invalid token.
> > Note: invalid tokens do not cause an error response since the client
> cannot handle such an error in a reasonable way.  Moreover, the purpose of
> the revocation request, invalidating the particular token, is already
> achieved.
>
> So if a client just made an incorrect call e.g. token=null then it
> will anyway receive a 200 OK and the user will think that logout was
> successful and a session closed. But internally the token may be
> stored in many places and even shared  between microservices/UI and
> other parties and it will remain still working.
>
> Can anybody take some actions and at least make some errata to the spec?
>
> P.S. adding to CC authors of the spec
>
> On Tue, 22 May 2018 at 20:29, Sergey Ponomarev  wrote:
> >
> > What is also should be discussed and specified is revoking of expired
> token. For example in Keycloak you can invalidate a session by expired
> token:
> >>
> >> It should be possible to logout a session with a token that is expired.
> This is to make sure that a user can invalidate a session if there's a
> suspicion that the refresh/offline token has been leaked. In such a case it
> could be that the real user has an expired refresh token while an attacker
> has been able to refresh the token and obtain a new not expired refresh
> token.
> >
> >
> > KEYCLOAK-3302
> >
> > Think this is doubtful but makes sense.
> >
> > To summarize: we have to create some threat model with description of
> possible use cases.
> >
> >
> > On Tue, 22 May 2018 at 18:18, Sergey Ponomarev 
> wrote:
> >>
> >> From OAuth perspective we can't say that the token should have some
> structure: they can be any random value in case of reference (opaque)
> tokens. But the Google's OAuth Server responds in this case with 400 error
> "invalid_token".
> >> The same can be used for JWTs with invalid sign or issuer.
> >> So it would be better if specification allow OAuth servers to respond
> with this error code if it clearly know that token was invalid by format.
> >>
> >> On Tue, 22 May 2018 at 17:51, Thomas Broyer  wrote:
> >>>
> >>> IFF the server processes it!
> >>> RFC 7009 says “An authorization server MAY ignore this parameter,
> particularly if it is able to detect the token type automatically.” which
> BTW is exactly my case.
> >>>
> >>> For months, my AS received requests with token=Array, and now receives
> requests with token=null. Those are clearly bugs in the client code, and
> because I return a 200 OK, the developers aren't aware of it.
> >>>
> >>> If tokens have an expected "structure", I think AS should probably
> return an error when the token value clearly is not a token (at one point I
> may change my implementation to do just that). As soon as it looks like a
> potential token though, then 200 OK sounds good to me.
> >>>
> >>> On Tue, May 22, 2018 at 4:34 PM Justin Richer  wrote:
> 
>  In that specific case, the token_type_hint value is invalid and can
> be rejected as an invalid_request.
> 
>   — Justin
> 
> 
>  On May 22, 2018, at 5:27 AM, Joseph Heenan 
> wrote:
> 
> 
>  I think one important point Sergey raised was that the response to
> the client from submitting the wrong token is the same 200 response as
> submitting a valid token, and that hugely 

[OAUTH-WG] [IANA #1216704] Expert Review for draft-ietf-oauth-iss-auth-resp (oauth-parameters) (2)

[Amanda Baber via RT]

Hi Hannes,

> I reviewed the draft and the IANA consideratoin section. The changes
> are good.
> I approve the question

Thanks! We'll make the registration today.

> PS: I would like to change my contact details from
> hannes.tschofe...@gmx.net
> to hannes.tschofe...@arm.com because I irregularly check my GMX
> account these
> days. How do I do this?

We actually don't have the gmx.net address in our expert directory -- we've 
been writing to hannes.tschofe...@arm.com, the OAuth list, and 
oauth-ext-rev...@ietf.org. I'll send a separate message to the arm.com address 
to check whether there are any issues with receiving mail from our ticketing 
system.

thanks,
Amanda

 
> Gesendet: Montag, 24. Januar 2022 um 23:59 Uhr
> Von: "Amanda Baber via RT" 
> An: Kein Empfänger
> Cc: r...@cert.org, oauth-ext-rev...@ietf.org,
> hannes.tschofe...@arm.com,
> oauth@ietf.org
> Betreff: [oauth-ext-review] [IANA #1216704] Expert Review for
> draft-ietf-oauth-iss-auth-resp (oauth-parameters) (2)
> Hi Roman,
> 
> We've received a request to move ahead with this OAuth Parameter
> registration
> without approval from Hannes (see below). As the AD for this document,
> can you
> approve?
> 
> The document: https://datatracker.ietf.org/doc/html/
> draft-ietf-oauth-iss-auth-resp
> 
> thanks,
> Amanda
> 
> On Mon Jan 24 22:36:59 2022, wpa...@rhosys.ch wrote:
> > Maybe we should come up with an alternative process that doesn't
> > involve a
> > single person sign-off. Is there a reason we need a "designated
> > expert"?
> >
> > Since no one on this thread has objected, I think it is fair to say,
> > we
> > don't need Hannes to sign-off. We should get this added.
> >
> > Amanda, please complete the registration.
> >
> > - Warren
> >
> > Warren Parad
> >
> > Founder, CTO
> > Secure your user data with IAM authorization as a service. Implement
> > Authress .
> >
> >
> > On Mon, Jan 24, 2022 at 11:09 PM Amanda Baber via RT <
> > drafts-expert-review-comm...@iana.org> wrote:
> >
> > > Hi Hannes,
> > >
> > > As the designated expert for OAuth Parameters, can you sign off on
> > > this
> > > registration?
> > >
> > > thanks,
> > > Amanda
> > >
> > > On Thu Jan 13 21:29:54 2022, bcampb...@pingidentity.com wrote:
> > > > Indeed, I believe that is exactly what the registration request
> > > > in the
> > > > draft asks to do
> > > > https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-
> > > > 05.html#name-oauth-parameters-registrati
> > > >
> > > > 5.2. OAuth Parameters Registration
> > > >
> > > > This specification updates the "iss" entry in the IANA "OAuth
> > > > Parameters" registry of [IANA.OAuth.Parameters] established by
> > > > [RFC6749].
> > > >
> > > > Parameter name: "iss"
> > > > Parameter usage location: authorization request, authorization
> > > > response
> > > > Change Controller: IETF
> > > > Specification Document(s): Section 2 of [[ this document ]],
> > > > [RFC9101], and Section 4.1.1 of [RFC7519].
> > > >
> > > > On Wed, Jan 12, 2022 at 7:29 PM Mike Jones  > > > 40microsoft@dmarc.ietf.org> wrote:
> > > >
> > > > > Note that the requested OAuth parameter to be registered "iss"
> > > > > has
> > > > > already
> > > > > been registered by RFC 9101 (The OAuth 2.0 Authorization
> > > > > Framework:
> > > > > JWT-Secured Authorization Request (JAR)) for Parameter Usage
> > > > > Location
> > > > > "authorization request". Fortunately, this use is compatible
> > > > > with
> > > > > that in
> > > > > draft-ietf-oauth-iss-auth-resp.
> > > > >
> > > > > I would be OK with draft-ietf-oauth-iss-auth-resp also
> > > > > registering it
> > > > > for
> > > > > usage "authorization response", as proposed in the draft, but
> > > > > the
> > > > > original
> > > > > registration for use "authorization request" by RFC 9191 should
> > > > > remain.
> > > > >
> > > > > -- Mike
> > > > >
> > > > > P.S. No, I'm not a designated expert for this registry. Hannes
> > > > > is
> > > > > the
> > > > > only DE currently appointed by the IESG.
> > > > >
> > > > > -Original Message-
> > > > > From: oauth-ext-review  On
> > > > > Behalf
> > > > > Of
> > > > > Amanda Baber via RT
> > > > > Sent: Thursday, January 6, 2022 4:50 PM
> > > > > Cc: oauth-ext-rev...@ietf.org; Hannes Tschofenig <
> > > > > hannes.tschofe...@arm.com>; oauth@ietf.org
> > > > > Subject: [oauth-ext-review] [IANA #1216704] Expert Review for
> > > > > draft-ietf-oauth-iss-auth-resp (oauth-parameters) (2)
> > > > >
> > > > > Hi Hannes,
> > > > >
> > > > > Although the IESG has approved the document, we need expert
> > > > > approval
> > > > > in
> > > > > order to move forward with the registration, unless the ADs
> > > > > specifically
> > > > > tell us to move ahead without it. Can you approve the OAuth
> > > > > Parameter
> > > > > registration in this document?
> > > > >
> > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-
> > > > > resp/
> > > > >
> > > > > thanks,
> > > > > Amanda
> > > > >
> > > > > On Tue Jan 04 

[OAUTH-WG] I-D Action: draft-ietf-oauth-rar-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Rich Authorization Requests
Authors : Torsten Lodderstedt
  Justin Richer
  Brian Campbell
Filename: draft-ietf-oauth-rar-10.txt
Pages   : 45
Date: 2022-01-26

Abstract:
   This document specifies a new parameter authorization_details that is
   used to carry fine-grained authorization data in OAuth messages.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-10.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-10


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [OAUTH-WG] Token Revocation error codes

[Sergey Ponomarev]

Hi and sorry for raising the four years old topic.

As a recup I reported a SECURITY VULNERABILITY on OAuth 2
specification level. It's minor (I hope) but still seen in the real
world AS implementation.
In short, to logout a user the revocation endpoint is called with the
user's token. And by a the RFC7009 the AS must always return 200 Ok
status code even if the token is invalid:

> The authorization server responds with HTTP status code 200 if the token has 
> been revoked successfully or if the client submitted an invalid token.
> Note: invalid tokens do not cause an error response since the client cannot 
> handle such an error in a reasonable way.  Moreover, the purpose of the 
> revocation request, invalidating the particular token, is already achieved.

So if a client just made an incorrect call e.g. token=null then it
will anyway receive a 200 OK and the user will think that logout was
successful and a session closed. But internally the token may be
stored in many places and even shared  between microservices/UI and
other parties and it will remain still working.

Can anybody take some actions and at least make some errata to the spec?

P.S. adding to CC authors of the spec

On Tue, 22 May 2018 at 20:29, Sergey Ponomarev  wrote:
>
> What is also should be discussed and specified is revoking of expired token. 
> For example in Keycloak you can invalidate a session by expired token:
>>
>> It should be possible to logout a session with a token that is expired. This 
>> is to make sure that a user can invalidate a session if there's a suspicion 
>> that the refresh/offline token has been leaked. In such a case it could be 
>> that the real user has an expired refresh token while an attacker has been 
>> able to refresh the token and obtain a new not expired refresh token.
>
>
> KEYCLOAK-3302
>
> Think this is doubtful but makes sense.
>
> To summarize: we have to create some threat model with description of 
> possible use cases.
>
>
> On Tue, 22 May 2018 at 18:18, Sergey Ponomarev  wrote:
>>
>> From OAuth perspective we can't say that the token should have some 
>> structure: they can be any random value in case of reference (opaque) 
>> tokens. But the Google's OAuth Server responds in this case with 400 error 
>> "invalid_token".
>> The same can be used for JWTs with invalid sign or issuer.
>> So it would be better if specification allow OAuth servers to respond with 
>> this error code if it clearly know that token was invalid by format.
>>
>> On Tue, 22 May 2018 at 17:51, Thomas Broyer  wrote:
>>>
>>> IFF the server processes it!
>>> RFC 7009 says “An authorization server MAY ignore this parameter, 
>>> particularly if it is able to detect the token type automatically.” which 
>>> BTW is exactly my case.
>>>
>>> For months, my AS received requests with token=Array, and now receives 
>>> requests with token=null. Those are clearly bugs in the client code, and 
>>> because I return a 200 OK, the developers aren't aware of it.
>>>
>>> If tokens have an expected "structure", I think AS should probably return 
>>> an error when the token value clearly is not a token (at one point I may 
>>> change my implementation to do just that). As soon as it looks like a 
>>> potential token though, then 200 OK sounds good to me.
>>>
>>> On Tue, May 22, 2018 at 4:34 PM Justin Richer  wrote:

 In that specific case, the token_type_hint value is invalid and can be 
 rejected as an invalid_request.

  — Justin


 On May 22, 2018, at 5:27 AM, Joseph Heenan  wrote:


 I think one important point Sergey raised was that the response to the 
 client from submitting the wrong token is the same 200 response as 
 submitting a valid token, and that hugely increases the chance that the 
 developer of the client app might submit the wrong token and never 
 realise. Making it easier for the developer of the client app to see that 
 they've done something wrong and need to fix their implementation seems 
 like a worthwhile goal to me, and that would appear to explain what google 
 are thinking with their responses.

 An example of an easy to make error that would get a 200 response is 
 getting the values the wrong way around, i.e. a body of:

  token=refresh_token_type_hint=45ghiukldjahdnhzdauz

 (as token_type_hint may be ignored by the server.)

 The example Sergey gave of the developer accidentally sending the id token 
 instead of the intended token seems quite likely to happen in the real 
 world too, and a 200 response in that case does seem wrong to me.


 Joseph


 On 21 May 2018, at 22:29, Justin Richer  wrote:

 I’m with George here: revocation is almost a best-effort request from the 
 client’s perspective. It sends a message to the server saying “hey I’m 
 done with this token, you can throw it out too”. If the server does revoke 
 the token, the client 

Re: [OAUTH-WG] [oauth-ext-review] [IANA #1216704] Expert Review for draft-ietf-oauth-iss-auth-resp (oauth-parameters) (2)

[Hannes Tschofenig]

Hi Amanda,

 

I reviewed the draft and the IANA consideratoin section. The changes are good. I approve the question

 

Ciao

Hannes

 

PS: I would like to change my contact details from hannes.tschofe...@gmx.net to hannes.tschofe...@arm.com because I irregularly check my GMX account these days. How do I do this?

 
 

Gesendet: Montag, 24. Januar 2022 um 23:59 Uhr
Von: "Amanda Baber via RT" 
An: Kein Empfänger
Cc: r...@cert.org, oauth-ext-rev...@ietf.org, hannes.tschofe...@arm.com, oauth@ietf.org
Betreff: [oauth-ext-review] [IANA #1216704] Expert Review for draft-ietf-oauth-iss-auth-resp (oauth-parameters) (2)

Hi Roman,

We've received a request to move ahead with this OAuth Parameter registration without approval from Hannes (see below). As the AD for this document, can you approve?

The document: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-iss-auth-resp

thanks,
Amanda

On Mon Jan 24 22:36:59 2022, wpa...@rhosys.ch wrote:
> Maybe we should come up with an alternative process that doesn't involve a
> single person sign-off. Is there a reason we need a "designated expert"?
>
> Since no one on this thread has objected, I think it is fair to say, we
> don't need Hannes to sign-off. We should get this added.
>
> Amanda, please complete the registration.
>
> - Warren
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Mon, Jan 24, 2022 at 11:09 PM Amanda Baber via RT <
> drafts-expert-review-comm...@iana.org> wrote:
>
> > Hi Hannes,
> >
> > As the designated expert for OAuth Parameters, can you sign off on this
> > registration?
> >
> > thanks,
> > Amanda
> >
> > On Thu Jan 13 21:29:54 2022, bcampb...@pingidentity.com wrote:
> > > Indeed, I believe that is exactly what the registration request in the
> > > draft asks to do
> > > https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-
> > > 05.html#name-oauth-parameters-registrati
> > >
> > > 5.2. OAuth Parameters Registration
> > >
> > > This specification updates the "iss" entry in the IANA "OAuth
> > > Parameters" registry of [IANA.OAuth.Parameters] established by
> > > [RFC6749].
> > >
> > > Parameter name: "iss"
> > > Parameter usage location: authorization request, authorization
> > > response
> > > Change Controller: IETF
> > > Specification Document(s): Section 2 of [[ this document ]],
> > > [RFC9101], and Section 4.1.1 of [RFC7519].
> > >
> > > On Wed, Jan 12, 2022 at 7:29 PM Mike Jones 
> > > 40microsoft@dmarc.ietf.org> wrote:
> > >
> > > > Note that the requested OAuth parameter to be registered "iss" has
> > > > already
> > > > been registered by RFC 9101 (The OAuth 2.0 Authorization Framework:
> > > > JWT-Secured Authorization Request (JAR)) for Parameter Usage Location
> > > > "authorization request". Fortunately, this use is compatible with
> > > > that in
> > > > draft-ietf-oauth-iss-auth-resp.
> > > >
> > > > I would be OK with draft-ietf-oauth-iss-auth-resp also registering it
> > > > for
> > > > usage "authorization response", as proposed in the draft, but the
> > > > original
> > > > registration for use "authorization request" by RFC 9191 should
> > > > remain.
> > > >
> > > > -- Mike
> > > >
> > > > P.S. No, I'm not a designated expert for this registry. Hannes is
> > > > the
> > > > only DE currently appointed by the IESG.
> > > >
> > > > -Original Message-
> > > > From: oauth-ext-review  On Behalf
> > > > Of
> > > > Amanda Baber via RT
> > > > Sent: Thursday, January 6, 2022 4:50 PM
> > > > Cc: oauth-ext-rev...@ietf.org; Hannes Tschofenig <
> > > > hannes.tschofe...@arm.com>; oauth@ietf.org
> > > > Subject: [oauth-ext-review] [IANA #1216704] Expert Review for
> > > > draft-ietf-oauth-iss-auth-resp (oauth-parameters) (2)
> > > >
> > > > Hi Hannes,
> > > >
> > > > Although the IESG has approved the document, we need expert approval
> > > > in
> > > > order to move forward with the registration, unless the ADs
> > > > specifically
> > > > tell us to move ahead without it. Can you approve the OAuth Parameter
> > > > registration in this document?
> > > >
> > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
> > > >
> > > > thanks,
> > > > Amanda
> > > >
> > > > On Tue Jan 04 13:21:14 2022, rifaat.s.i...@gmail.com wrote:
> > > > > Hannes,
> > > > >
> > > > > Can you please take a look at this request to allow us to make
> > > > > progress with this document?
> > > > >
> > > > > Thanks,
> > > > > Rifaat
> > > > >
> > > > >
> > > > > On Mon, Jan 3, 2022 at 8:58 PM Amanda Baber via RT <
> > > > > drafts-expert-review-comm...@iana.org> wrote:
> > > > >
> > > > > > Hi Hannes,
> > > > > >
> > > > > > Have you had a chance to review the OAuth Parameters request in
> > > > > > this
> > > > > > document?
> > > > > >
> > > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > Amanda Baber
> > > > > > IANA Operations Manager
> > >