Re: [OAUTH-WG] Tuesday side meeting agenda

[Rifaat Shekh-Yusef]

Hi Kai,

These slides are already on the OAuth WG meeting material.
I have added the links to the two related presentations:
https://datatracker.ietf.org/meeting/115/materials/slides-115-oauth-fine-grained-transactional-authorization-sgnl-proposal
https://datatracker.ietf.org/meeting/115/materials/slides-115-oauth-identity-chaining-using-oauth-token-exchange

Regards,
 Rifaat




On Wed, Nov 16, 2022 at 2:37 AM Kai Lehmann  wrote:

> Hi Rifaat,
>
>
>
> the ones regarding the Fine Grained Authorization discussion.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From: *Rifaat Shekh-Yusef 
> *Date: *Tuesday, 15. November 2022 at 20:45
> *To: *Kai Lehmann 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] Tuesday side meeting agenda
>
>
>
> Hi Kai,
>
>
>
> Unfortunately, we did not take notes for these meetings.
>
> Which slides specifically are you referring to?
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
> On Tue, Nov 15, 2022 at 4:14 AM Kai Lehmann  wrote:
>
> Hi Rifaat,
>
>
>
> are the slides/meeting notes available for the side meetings somewhere?
> There have been some slides shown and discussed during the side-meeting on
> Thursday and I would like to revisit them. If there are slides/notes
> available, it might be a good idea to reference them here:
>
>
>
> https://wiki.ietf.org/meeting/115/sidemeetings
>
>
>
> Thanks,
>
> Kai
>
>
>
>
>
> *From: *OAuth  on behalf of Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com>
> *Date: *Tuesday, 15. November 2022 at 00:44
> *To: *Dmitry Telegin 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] Tuesday side meeting agenda
>
>
>
> Hi Dmitry,
>
>
>
> Unfortunately, the side meetings are not recorded.
>
>
>
> Regards,
>
>  Rifaat
>
>
>
> On Monday, November 14, 2022, Dmitry Telegin  wrote:
>
> Hello Rifaat,
>
>
>
> Are there plans to publish side meetings agendas/slides/recordings, for
> those who didn't manage to attend?
>
>
>
> Thanks,
>
> Dmitry
>
>
>
> On Tue, Nov 8, 2022 at 11:16 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
> The side meeting is at 2:00pm at Richmond 6.
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
> On Tue, Nov 8, 2022 at 10:14 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
> All,
>
>
>
> The agenda for today's side meeting is the following:
>
> 1. WG Github, OAuth 2.1/Browser-based App - 30 minutes
>
> 2. DPoP - AD and FAPI feedback - 30 minutes
>
>
>
> We only have 1 hour today because of a conflict with the COSE WG.
>
>
>
> Regards,
>
>  Rifaat
>
>
>
> ___
> 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-WG] [IANA #1261154] expert review for draft-ietf-oauth-rar (OAuth Parameters - OAuth Extensions Error)

[Sabrina Tanamal via RT]

Hi Hannes (cc: oauth wg),

As the designated expert for the OAuth Parameters and OAuth Extensions Error 
registries, can you review the proposed registrations in draft-ietf-oauth-rar 
for us? Please see

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar

The due date is December 1st.

If this is OK, when the IESG approves the document for publication, we'll make 
the registrations at

https://www.iana.org/assignments/oauth-parameters

thanks,

Sabrina Tanamal
Lead IANA Services Specialist

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

Re: [OAUTH-WG] [IANA #1261154] expert review for draft-ietf-oauth-rar (OAuth Parameters - OAuth Extensions Error)

[Warren Parad]

Hello Sabrina,

In the future I want to make sure that there is more than one owner for
this process. In the past it sometimes was quite a challenge to get timely
approvals.

Would you be able to point me to the right place to ensure we can extend
the ownership?

Thanks,
Warren

On Thu, Nov 17, 2022, 19:09 Sabrina Tanamal via RT <
drafts-expert-review-comm...@iana.org> wrote:

> Hi Hannes (cc: oauth wg),
>
> As the designated expert for the OAuth Parameters and OAuth Extensions
> Error registries, can you review the proposed registrations in
> draft-ietf-oauth-rar for us? Please see
>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar
>
> The due date is December 1st.
>
> If this is OK, when the IESG approves the document for publication, we'll
> make the registrations at
>
> https://www.iana.org/assignments/oauth-parameters
>
> thanks,
>
> Sabrina Tanamal
> Lead IANA Services Specialist
>
> ___
> 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-WG] Genart last call review of draft-ietf-oauth-rar-15

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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-rar-??
Reviewer: Robert Sparks
Review Date: 2022-11-17
IETF LC End Date: 2022-11-17
IESG Telechat date: Not scheduled for a telechat

Summary:

Major issues:

Minor issues:

Nits/editorial comments:



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

Re: [OAUTH-WG] [Last-Call] Genart last call review of draft-ietf-oauth-rar-15

[Robert Sparks]

Apologies - an upload fumble left -00 empty. I've revised it to have 
content at -01.


RjS

On 11/17/22 4:36 PM, Robert Sparks via Datatracker wrote:

Reviewer: Robert Sparks
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-rar-??
Reviewer: Robert Sparks
Review Date: 2022-11-17
IETF LC End Date: 2022-11-17
IESG Telechat date: Not scheduled for a telechat

Summary:

Major issues:

Minor issues:

Nits/editorial comments:





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

Re: [OAUTH-WG] [Gen-art] [Last-Call] Genart last call review of draft-ietf-oauth-rar-15

[Robert Sparks]

On 11/17/22 4:44 PM, Robert Sparks wrote:
Apologies - an upload fumble left -00 empty. I've revised it to have 
content at -01.


Which I'll also paste here for convenience:

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-rar-14 (<- that was a typo - I really did 
review 15)

Reviewer: Robert Sparks
Review Date: 2022-11-17
IETF LC End Date: 2022-11-17
IESG Telechat date: Not scheduled for a telechat

Summary:

Major issues: Essentially ready for publication as a Proposed Standard 
RFC, but with issues to discuss before publication


I have two major issues that I think need discussion:

Major Issue 1) The document seems to be specifying a new way of 
comparing json names, claiming it is what RFC8259 requires, but I 
disagree that RFC8259 says what this document is claiming. If I'm 
correct, the document is trying to rely on the text in section 7 of 
RFC8259 to support the idea that implementation MUST NOT alter the json 
names (such as applying Unicode normalization) before comparison and 
that the comparison MUST be performed octet-by-octet. Rather, section 7 
says something more like "you better escape and unescape stuff correctly 
if you’re going to do unicode codepoint by codepoint comparison" which 
is a completely different statement.


If I'm right, and this is a new comparison rule that goes beyond what 
JSON itself defines, I think the group should seek extra guidance from 
Unicode experts. If I'm wrong and this behavior is defined somewhere 
else, please provide a better pointer to the definition.


In many environments, its unusual for an implementation relying on a 
stack below it to have any say at all on whether normalization is going 
to be applied to the unicode before the application gets to look. Rather 
than trying to work around the problem you've identified with 
normalization by specifying the comparison algorithm, consider just 
making stronger statements about the strings used in the json names the 
document defines. Why _can't_ you restrict the authorization_details 
values to ascii? If it's because you want to present the string to a 
user, consider putting a presentation string elsewhere in the json that 
is not used for comparison.


Major Issue 2) The suggested pattern demonstrated starting in figure 16 
(using [] to mean "let the user choose") seems underspecified. If the 
point is that different APIs may invent different mechanics _like_ this, 
and that this is only an example. Make it much clearer that this is an 
example. If this is a pattern you expect all APIs to follow, then more 
description is warranted. Is it intended that a user could add and 
remove things arbitrarily to such lists? For instance is it intended 
that this support an interaction where the client is asking for 
permission to operate on account A, and the user can say "no, but you 
can operate on account B"?


Minor issues:

Section 2: What does "The AS MUST ensure that there is no collision 
between different authorization details types that it supports." mean? 
How is this a 2119 requirement? I _think_ you're trying to point out 
that the authorization_details string is a unique-key at any AS and that 
that has consequences on the API _designer_, but I don't know what is 
expected of an AS coder here. Some clearer words are needed.


Section 7: Please expand on, or rephrase, "if these are deemed of no 
intended use for the client." Could you just delete the phrase? If you 
are only explaining why an AS might do this, make it clear that it's an 
example (and split the example into a separate sentence). If this is the 
_only_ reason an AS might omit values in the token Response, then more 
detail is needed.



Nits/editorial comments:

Throughout the document, there is a mix of "authorization_details" and 
"authorization details". It is not completely consistent using one when 
talking about the parameter and the other when talking about the general 
concept of details about authorization. Please inspect each occurrence 
and verify that it is using the correct form.


Introduction: suggest changing 'defines the parameter scope' to 'defines 
the parameter "scope"'


Introduction just after figure 1 - expand AS (first use).

Section 2.2: Please rework the sentence where you mention "the cartesian 
product" and remove the reference - it is not helpful. Instead of "That 
is to say," just say it.


Section 6.1, discussion just after Figure 13. Consider rewriting the 
sentence to avoid the term "non-subsuming". Think about translation into 
other languages.


Section 9.2 intro to Figure 21: something is missing from this sentence. 
The RS: at the end is either not needed or needs more words?


Section 1

Re: [OAUTH-WG] DPoP questions (post IETF 115), part 1

[Dmitry Telegin]

Agreed on general guidance, will try to draft the text. Should I post it
here first or go straight to GitHub?

On Wed, Nov 16, 2022 at 1:49 PM Brian Campbell  wrote:

>
>
> On Mon, Nov 14, 2022 at 5:18 PM Dmitry Telegin  40backbase@dmarc.ietf.org> wrote:
>
>>
>> To sum up, my idea is that in cases when we can unambiguously establish
>> the scheme used, we should include error info into the corresponding
>> challenge only. In cases of ambiguity, both challenges should be used to
>> deliver error info. If this make sense, could it be worth covering this
>> topic in the spec?
>>
>
> Is there some text you could propose that offers guidance along those
> lines? Probably to go in sec 7.2, which is where multiple authentication
> schemes are mentioned. Your idea seems like a generally appropriate
> approach. I don't believe there's necessarily a right or wrong though. Some
> general guidance could be helpful but I'd be hesitant about going further.
>
>
>
> *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] DPoP questions (post IETF 115), part 2

[Dmitry Telegin]

Thanks Brian, it's clear now. Shame on me for having overlooked that DPoP
bit in Sec 3.

Dmitry

On Tue, Nov 15, 2022 at 10:20 PM Brian Campbell  wrote:

> Hello Dmitry,
>
> TLDR: yes DPoP and Step-Up can be used together.
>
> The first sentence in the section of step-up that describes the new bits
> for the WWW-Authenticate even explicitly mentions DPoP:
> https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-06.html#section-3
> and other schemes that are like RFC 6750. The process of extending/building
> on RFC 6750 seemed pretty open ended when I looked at the details. There's
> a registry for the HTTP auth scheme and one for OAuth error codes. I did my
> best to define DPoP and step-up stuff, given what was already in place, in
> a reasonable way. And that should match more or less what you're looking
> for.
>
> I don't know specifics around conformance but I think that DPoP is being
> worked on or planned with the FAPI 2.0 tests.
>
>
>
>
> On Mon, Nov 14, 2022 at 5:42 PM Dmitry Telegin  40backbase@dmarc.ietf.org> wrote:
>
>> - DPoP and Step-Up (hello Brian :)
>>
>> TL;DR: can we use DPoP and Step-Up together?
>>
>> The question is probably more about understanding of the process rather
>> than technical details. If I understand correctly, Step-Up is meant to
>> amend/extend RFC 6750. Can we say that the features defined in Step-Up
>> automatically become available for the specs that build on top of 6750,
>> e.g. DPoP? In other words, would the following response be considered valid:
>>
>> HTTP/1.1 401 Unauthorized
>> WWW-Authenticate: DPoP algs="ES256 PS256", 
>> error="insufficient_user_authentication",
>>   error_description="A different authentication level is required",
>>   acr_values="myACR"
>>
>>
>> - DPoP conformance
>> Is there any "official" conformance suite that could be used to test an
>> AS/RS for DPoP conformance? would that be the OIDC Conformance Suite (its
>> FAPI2 part)?
>>
>> Thanks,
>> Dmitry
>> ___
>> 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] DPoP questions (post IETF 115), part 1

[Brian Campbell]

Either way is okay. But straight to GitHub with a PR is probably easier
https://github.com/danielfett/draft-dpop

On Thu, Nov 17, 2022 at 5:18 PM Dmitry Telegin  wrote:

> Agreed on general guidance, will try to draft the text. Should I post it
> here first or go straight to GitHub?
>
> On Wed, Nov 16, 2022 at 1:49 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>>
>>
>> On Mon, Nov 14, 2022 at 5:18 PM Dmitry Telegin > 40backbase@dmarc.ietf.org> wrote:
>>
>>>
>>> To sum up, my idea is that in cases when we can unambiguously establish
>>> the scheme used, we should include error info into the corresponding
>>> challenge only. In cases of ambiguity, both challenges should be used to
>>> deliver error info. If this make sense, could it be worth covering this
>>> topic in the spec?
>>>
>>
>> Is there some text you could propose that offers guidance along those
>> lines? Probably to go in sec 7.2, which is where multiple authentication
>> schemes are mentioned. Your idea seems like a generally appropriate
>> approach. I don't believe there's necessarily a right or wrong though. Some
>> general guidance could be helpful but I'd be hesitant about going further.
>>
>>
>>
>> *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.*
>
>

-- 
_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