[OAUTH-WG] Fwd: IETF 116 Preliminary Agenda

[Rifaat Shekh-Yusef]

Based on the preliminary agenda, we have two official sessions:
*Tuesday *and *Friday*, both at *9:30-11:30*.

Regards,
 Rifaat


-- Forwarded message -
From: IETF Agenda 
Date: Fri, Feb 24, 2023 at 5:50 PM
Subject: IETF 116 Preliminary Agenda
To: IETF Announcement List 
Cc: , <116...@ietf.org>


IETF 116
Yokohama, Japan
March 25-31, 2023
Hosted By: WIDE


The IETF 116 Preliminary Agenda has been posted. The final agenda will be
published on Friday, March 3, 2023.

https://datatracker.ietf.org/meeting/116/agenda.html
https://datatracker.ietf.org/meeting/116/agenda.txt

The preliminary agenda includes all planned WG, RG, and BoF sessions.
Information about side meetings will be available when the final agenda is
posted.

IETF 116 Information: https://www.ietf.org/how/meetings/116/
Register online at: https://registration.ietf.org/116/

Don’t forget to register for these exciting IETF 116 events!


Social Event

The Osanbashi Pier's multipurpose hall will be transformed into a wonderful
social event location for IETF 116 attendees in Yokohama.

Attendees will be delighted by the music of internationally renowned artist
Kaoru Watanabe, delicious food and a Japanese sake corner introducing
attendees to sake from all thirteen sake breweries in Kanagawa Prefecture.

- Date: Thursday, March 30

- Start/End Times: 19:00 – 21:30

- Cost per ticket: $25 per ticket

- Limit of tickets per attendee: Two per attendee.

More information:
https://www.ietf.org/how/meetings/116/social/
https://ietf116.jp/social-event/


Hackathon

Onsite signup: https://registration.ietf.org/116/new/hackathon_onsite/
Remote signup: https://registration.ietf.org/116/new/hackathon_remote/
More information:
https://www.ietf.org/how/runningcode/hackathons/116-hackathon/
Keep up to date by subscribing to:
https://www.ietf.org/mailman/listinfo/hackathon


Code Sprint

More information and signups: https://notes.ietf.org/notes-ietf-116-tools#

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-step-up-authn-challenge-11

[Vittorio Bertocci]

Thanks Christer for your thorough review!
A new draft (
https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-12.html)
reflecting changes resulting from the feedback has been published.
Comments inline

On Thu, Feb 23, 2023 at 9:13 AM Christer Holmberg via Datatracker <
nore...@ietf.org> wrote:

>
>   This message originated outside your organization.
>
>
> Reviewer: Christer Holmberg
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-oauth-step-up-authn-challenge-11
> Reviewer: Christer Holmberg
> Review Date: 2023-02-23
> IETF LC End Date: 2023-03-03
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: The document is well written, and easy to read. However, I have
> found
> some issues that I would like the authors to address.
>
> Major issues:
>
>   QMa1: General
>
> As the document defines a new error code, and define new
> WWW-Authenticate
> parameters, should the document not be an Update to RFC 6750?
>
>
It's a good point to consider. Our rationale is that this document
leverages many different extension points baked in a number of existing
specs, hence it doesn't seem a slam dunk to determine which one we should
"inherit" from.


> 
>
>   QMa2: Section 4
>
> The text defines the procedures for the client.
>
> But, what if the client does not support the new error code and the new
> WWW-A parameters? I think there should be some backward compatibility
> text
> (or reference, if defined elsewhere).
>
> Especially it should be clear that the server will not receive the
> WWW-A
> parameters in the new request if the client does not support them.
>
>
This is a tricky one. Technically, every extension starts its existence
with zero support from existing clients. Implementers should be familiar
with this, and specs stipulate that any entity receiving a parameter it
doesn't understand to ignore that parameter, from which it follows that
whatever semantic or directive that parameter carries will remain not
executed. Saying in the document that clients not supporting the parameters
we are defining here will not achieve the goals of the spec seem somewhat
redundant. What do you think?


> 
>
> Minor issues:
>
>   QMi1: Section 3
>
> Can the new WWW-Authenticate parameters only be used with the new error
> code? If so, please indicate it.
>
> There doesn't seem to be any obvious reasons to ban future extensions from
using those parameters, nor there appear to be obvious scenarios where we
would proactively suggest doing so: that's our rationale for not having
commented on this aspect in the document.


> ---
>
>   QMi2: Section 3
>
> Is the max_age value required to be given as a string value (as in the
> example)? If so, please indicate it.
>
>
 Good question. It doesn't have to be a string value. It can be a token or
quoted-string. We will clarify.

---
>
> Nits/editorial comments:
>
>   QNi1: General
>
> Throughout the document uses "doesn't", "isn't" and "it's". I suggest
> replacing those with "does not", "is not" and "it is".
>
>
Alright. That will definitely make the document more formal sounding.


>
>   QNi2: Abstract
>
> The text starts by talking about resource servers, requests etc.
> Eventhough
> the document title mentions OAuth 2.0, I think it would also be good to
> mention it in the beginning of the Abstract.
>
> E.g.,
>
> "When OAuth 2.0 is used, it is not uncommon for..."
>
>
The scenario we describe is a generic occurrence for any API surfacing
resources requiring different access levels.
We chose  OAuth as the framework within which we specify a method to
address the scenario, and there will be no doubt in the mind of the reader
about that (the title and the concrete guidance take care of it), however
the scenario remains generic hence restricting it to OAuth in the
description at the abstract wouldn't necessarily add to that.


> 
>
>   QNi3: Introduction
>
> Similar to the Abstract, I think it would be good to mention OAuth 2.0
> in
> the beginning.
>
> See above for a clarification on the pattern operating at the generic API
level, regardless of implementation details, and guidance on how to
implement it (OAuth specific).


> Also, I am not sure what "API authorization scenario" means.
>
Could you say "OAuth 2.0 authorization scenario"?
>
> The need for API to implement authorization logic is independent on the
specific protocols the API implementers decided to use. What makes this
OAuth specific is the fact that we use OAuth framework constructs to get
the job done, but the scenario remains a high 

[OAUTH-WG] I-D Action: draft-ietf-oauth-step-up-authn-challenge-12.txt

[internet-drafts]

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

Title   : OAuth 2.0 Step-up Authentication Challenge Protocol
Authors : Vittorio Bertocci
  Brian Campbell
  Filename: draft-ietf-oauth-step-up-authn-challenge-12.txt
  Pages   : 17
  Date: 2023-02-24

Abstract:
   It is not uncommon for resource servers to require different
   authentication strengths or recentness according to the
   characteristics of a request.  This document introduces a mechanism
   for a resource server to signal to a client that the authentication
   event associated with the access token of the current request does
   not meet its authentication requirements and specify how to meet
   them.  This document also codifies a mechanism for a client to
   request that an authorization server achieve a specific
   authentication strength or recentness when processing an
   authorization request.


The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-12.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-step-up-authn-challenge-12


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