Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?

[Benjamin Kaduk]

On Mon, Apr 27, 2020 at 12:58:09PM -0400, Justin Richer wrote:
> I agree that any URI could be used but that it MUST be understood by the AS 
> to be local to the AS (and not something that can be impersonated by an 
> attacker). I wouldn’t even go so far as RECOMMENDED, but it’s certainly an 
> option.

IIUC BCP 190 has similar thoughts on the matter...

-Ben

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

Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?

[Brian Campbell]

Yeah, I hadn't really been thinking of going so far as making it
RECOMMENDED either but more of just providing an easy option for those that
would choose to use it.



On Mon, Apr 27, 2020 at 10:58 AM Justin Richer  wrote:

> I agree that any URI could be used but that it MUST be understood by the
> AS to be local to the AS (and not something that can be impersonated by an
> attacker). I wouldn’t even go so far as RECOMMENDED, but it’s certainly an
> option.
>
>  — Justin
>
> On Apr 27, 2020, at 4:41 AM, Filip Skokan  wrote:
>
> I believe implementers should be free to devise their own URIs and not be
> locked down to one by the spec, at the same time,
> and RFC6755 subnamespace would be good for guidance.
>
> So, I would suggest it be RECOMMENDED to use e.g.
> `urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also
> that any URN or URL will do if the circumstances call for it.
>
> Best,
> *Filip*
>
>
> On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> another topic from last week’s virtual meeting.
>>
>> Shall there be guidance on the request URI structure?
>>
>> Please state your opinion.
>>
>> thanks in advance,
>> Torsten.
>> ___
>> 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
>

-- 
_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] PAR and client metadata

[Brian Campbell]

require_pushed_authorization_requests works for me and is maybe/arguably a
bit better by being more consistent with other names.

On Mon, Apr 27, 2020 at 12:58 PM Filip Skokan  wrote:

> Alternatively, `require_pushed_authorization_requests`. Since we already
> have the `*require_*request_uri_registration` server and `*require_*
> auth_time` client metadata properties.
>
> WDYT?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> I think this topic has several aspects:
>> - Is the client required to use PAR only? Doesn’t this also mean it is
>> required to use request_uri only?
>> - Is there a need to separate those to questions or shall we treat this
>> as the same?
>> - Who decides whether PAR and request_uri are required? The client for
>> its instances or the AS for the whole deployment?
>>
>> I’m in favour of coupling enforced PAR use with enforced request_uri use
>> even though it means the setting is useful with PAR only, not with all
>> JAR-based clients.
>> I think both the client as well as the AS should be able to declare
>> forced PAR. If the AS is able to basically turn of traditional
>> authorization requests, it can consequently utilize the changed protocol
>> properties in terms of security and robustness in its deployment. This
>> means, for example, the AS no longer needs to require pre-registered
>> redirect URIs for confidential clients. It also means, the AS can use
>> voluminous claims/authorization details objects without worrying about
>> fragile long request URLs.
>>
>> So here is my proposal:
>>
>> 1) Add server metadata parameter “pushed_authorization_requests_only” of
>> type boolean - It requires any client to use PAR, the AS will refuse to
>> process any authorization request containing parameters other than
>> request_uri + client_id (as required by
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
>> request parameters need to be passed via PAR.
>> 2) Add client registration parameter “pushed_authorization_requests_only”
>> - It requires this client to use PAR only. The AS won’t accept any
>> authorization request containing more than request_uri + client_id for that
>> particular client.
>>
>> What are your thoughts?
>>
>> best regards,
>> Torsten.
>>
>> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov 
>> wrote:
>> >
>> > In a off-list conversation Torsten floated the idea of letting
>> confidential PAR-only clients register without a redirect_uris and having
>> this "PAR only" parameter will enable that.
>> >
>> > A "PAR only" parameter will also prevent client developers from
>> accidentally making plain authz requests (for clients that rely on PAR for
>> the extra security).
>> >
>> > Vladimir
>> >
>> > On 16/04/2020 18:39, Brian Campbell wrote:
>> >>
>> >>
>> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle > 40amazon@dmarc.ietf.org> wrote:
>> >> As I think through this, I’m struggling to identify the threats this
>> actually helps mitigate.
>> >>
>> >> A client metadata parameter implies that the value may be different
>> for different clients, and that any given client won’t already know via
>> other means whether or not it needs to use PAR. That means we’re only
>> talking about dynamic clients since statically registered clients already
>> have some proprietary out-of-band registration mechanism (e.g., a developer
>> console).
>> >>
>> >> As I tried to articulate in the original email and Filip also
>> mentioned in a different fork of this email thread, defining metadata can
>> be beneficial even when it's not used dynamically at runtime. So we're not
>> only talking about dynamic clients.
>> >>
>> >>
>> >>
>> >> A client metadata parameter also implies that the AS allows some
>> clients to make non-PAR requests (otherwise it would be an AS metadata
>> parameter).
>> >>
>> >> A per client setting seems necessary for existing ASs to roll out PAR
>> support over time or just generally in support of diverse client
>> capabilities and requirements.
>> >>
>> >>
>> >> If that’s the case then presumably a malicious party could register
>> their own client that doesn’t use PAR.
>> >>
>> >> So it seems to me that the only scenario that this parameter would
>> protect against is a malicious party impersonating a dynamically registered
>> client that uses PAR. That wouldn’t apply to Mix-Up, since in that attack
>> the attacker uses its own client.
>> >>
>> >> This client metadata parameter is meant to be something that would
>> prevent a malicious actor from controlling the content of the authz request
>> parameters, which could be done by crafting the link and tricking a user
>> into following it. I mentioned mix-up as an example because the first
>> variant of it desribed at
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
>> does something along those lines.
>> >>
>> >>
>> >>
>> >> If a client can do PAR, 

Re: [OAUTH-WG] PAR and client metadata

[Filip Skokan]

Alternatively, `require_pushed_authorization_requests`. Since we already
have the `*require_*request_uri_registration` server and `*require_*
auth_time` client metadata properties.

WDYT?

S pozdravem,
*Filip Skokan*


On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt  wrote:

> Hi all,
>
> I think this topic has several aspects:
> - Is the client required to use PAR only? Doesn’t this also mean it is
> required to use request_uri only?
> - Is there a need to separate those to questions or shall we treat this as
> the same?
> - Who decides whether PAR and request_uri are required? The client for its
> instances or the AS for the whole deployment?
>
> I’m in favour of coupling enforced PAR use with enforced request_uri use
> even though it means the setting is useful with PAR only, not with all
> JAR-based clients.
> I think both the client as well as the AS should be able to declare forced
> PAR. If the AS is able to basically turn of traditional authorization
> requests, it can consequently utilize the changed protocol properties in
> terms of security and robustness in its deployment. This means, for
> example, the AS no longer needs to require pre-registered redirect URIs for
> confidential clients. It also means, the AS can use voluminous
> claims/authorization details objects without worrying about fragile long
> request URLs.
>
> So here is my proposal:
>
> 1) Add server metadata parameter “pushed_authorization_requests_only” of
> type boolean - It requires any client to use PAR, the AS will refuse to
> process any authorization request containing parameters other than
> request_uri + client_id (as required by
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
> request parameters need to be passed via PAR.
> 2) Add client registration parameter “pushed_authorization_requests_only”
> - It requires this client to use PAR only. The AS won’t accept any
> authorization request containing more than request_uri + client_id for that
> particular client.
>
> What are your thoughts?
>
> best regards,
> Torsten.
>
> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov 
> wrote:
> >
> > In a off-list conversation Torsten floated the idea of letting
> confidential PAR-only clients register without a redirect_uris and having
> this "PAR only" parameter will enable that.
> >
> > A "PAR only" parameter will also prevent client developers from
> accidentally making plain authz requests (for clients that rely on PAR for
> the extra security).
> >
> > Vladimir
> >
> > On 16/04/2020 18:39, Brian Campbell wrote:
> >>
> >>
> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
> >> As I think through this, I’m struggling to identify the threats this
> actually helps mitigate.
> >>
> >> A client metadata parameter implies that the value may be different for
> different clients, and that any given client won’t already know via other
> means whether or not it needs to use PAR. That means we’re only talking
> about dynamic clients since statically registered clients already have some
> proprietary out-of-band registration mechanism (e.g., a developer console).
> >>
> >> As I tried to articulate in the original email and Filip also mentioned
> in a different fork of this email thread, defining metadata can be
> beneficial even when it's not used dynamically at runtime. So we're not
> only talking about dynamic clients.
> >>
> >>
> >>
> >> A client metadata parameter also implies that the AS allows some
> clients to make non-PAR requests (otherwise it would be an AS metadata
> parameter).
> >>
> >> A per client setting seems necessary for existing ASs to roll out PAR
> support over time or just generally in support of diverse client
> capabilities and requirements.
> >>
> >>
> >> If that’s the case then presumably a malicious party could register
> their own client that doesn’t use PAR.
> >>
> >> So it seems to me that the only scenario that this parameter would
> protect against is a malicious party impersonating a dynamically registered
> client that uses PAR. That wouldn’t apply to Mix-Up, since in that attack
> the attacker uses its own client.
> >>
> >> This client metadata parameter is meant to be something that would
> prevent a malicious actor from controlling the content of the authz request
> parameters, which could be done by crafting the link and tricking a user
> into following it. I mentioned mix-up as an example because the first
> variant of it desribed at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4..4.1
> does something along those lines.
> >>
> >>
> >>
> >> If a client can do PAR, then it can do authorization code grant and
> PKCE, so we’re further limited to scenarios where the attacker does not
> need to be able to redeem the authorization code themselves. What threats
> fall into this category?
> >>
> >> —
> >> Annabelle Backman (she/her)
> >> AWS Identity
> >>
> >>> On Apr 14, 2020, at 2:44 PM, Brian Campbell  

Re: [OAUTH-WG] PAR - Can AS/client require request object?

[Brian Campbell]

While there are certainly different permutations and contexts of use that
could be imagine, I tend to agree with Filip here in not seeing a strong
need to define new PAR specific metadata around signing/encryption of the
request object.

On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan  wrote:

> Considering there's going to be a setting that forces clients to use PAR
> (other mailinglist thread), then we should rely on the existing
> `request_object_signing_alg` presence to indicate a Request Object must be
> used (as suggested by this upcoming OIDC Core errata
> ),
> regardless of it being PAR or JAR. I don't see the need for a PAR specific
> metadata, for one - implementations wouldn't be easily able to re-use of
> existing pipelines, two - yes the contexts differ but do you think clients
> will be using both channels at the same time? And even if so, the Request
> Object is the same therefore its applicable to both channels the same.
>
> Best,
> *Filip Skokan*
>
>
> On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> this is one of the topics we quickly flipped through in the virtual
>> meeting last week.
>>
>> I see the following open questions:
>> - Can the client require its instances to use request objects only.
>> - Are there further requirements on the properties of these objects?
>> Signed only, Signed and encrypted, algorithms?
>> - Can an AS require ALL clients to use request objects only?
>> - Further requirements here as well?
>> - Is this tied to PAR or relevant for JAR as well?
>>
>> In my opinion, client as well as AS should be able to control enforced
>> use of request objects.
>>
>> I could imagine the setting for JAR request objects (“request" parameter)
>> and request objects in the PAR context differ, as the first case goes
>> through the user’s browser whereas the PAR case goes direct from client to
>> AS via a TLS protected channel. I therefore feel the settings should be PAR
>> specific.
>>
>> What do you think?
>>
>> best regards,
>> Torsten.
>> ___
>> 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
>

-- 
_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] PAR and client metadata

[Brian Campbell]

I think your proposal hits the right level of granularity and usefulness.
And I'm thrilled that you went ahead and offered up a name.

On Sun, Apr 26, 2020 at 8:58 AM Torsten Lodderstedt  wrote:

> Hi all,
>
> I think this topic has several aspects:
> - Is the client required to use PAR only? Doesn’t this also mean it is
> required to use request_uri only?
> - Is there a need to separate those to questions or shall we treat this as
> the same?
> - Who decides whether PAR and request_uri are required? The client for its
> instances or the AS for the whole deployment?
>
> I’m in favour of coupling enforced PAR use with enforced request_uri use
> even though it means the setting is useful with PAR only, not with all
> JAR-based clients.
> I think both the client as well as the AS should be able to declare forced
> PAR. If the AS is able to basically turn of traditional authorization
> requests, it can consequently utilize the changed protocol properties in
> terms of security and robustness in its deployment. This means, for
> example, the AS no longer needs to require pre-registered redirect URIs for
> confidential clients. It also means, the AS can use voluminous
> claims/authorization details objects without worrying about fragile long
> request URLs.
>
> So here is my proposal:
>
> 1) Add server metadata parameter “pushed_authorization_requests_only” of
> type boolean - It requires any client to use PAR, the AS will refuse to
> process any authorization request containing parameters other than
> request_uri + client_id (as required by
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
> request parameters need to be passed via PAR.
> 2) Add client registration parameter “pushed_authorization_requests_only”
> - It requires this client to use PAR only. The AS won’t accept any
> authorization request containing more than request_uri + client_id for that
> particular client.
>
> What are your thoughts?
>
> best regards,
> Torsten.
>
> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov 
> wrote:
> >
> > In a off-list conversation Torsten floated the idea of letting
> confidential PAR-only clients register without a redirect_uris and having
> this "PAR only" parameter will enable that.
> >
> > A "PAR only" parameter will also prevent client developers from
> accidentally making plain authz requests (for clients that rely on PAR for
> the extra security).
> >
> > Vladimir
> >
> > On 16/04/2020 18:39, Brian Campbell wrote:
> >>
> >>
> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
> >> As I think through this, I’m struggling to identify the threats this
> actually helps mitigate.
> >>
> >> A client metadata parameter implies that the value may be different for
> different clients, and that any given client won’t already know via other
> means whether or not it needs to use PAR. That means we’re only talking
> about dynamic clients since statically registered clients already have some
> proprietary out-of-band registration mechanism (e.g., a developer console).
> >>
> >> As I tried to articulate in the original email and Filip also mentioned
> in a different fork of this email thread, defining metadata can be
> beneficial even when it's not used dynamically at runtime. So we're not
> only talking about dynamic clients.
> >>
> >>
> >>
> >> A client metadata parameter also implies that the AS allows some
> clients to make non-PAR requests (otherwise it would be an AS metadata
> parameter).
> >>
> >> A per client setting seems necessary for existing ASs to roll out PAR
> support over time or just generally in support of diverse client
> capabilities and requirements.
> >>
> >>
> >> If that’s the case then presumably a malicious party could register
> their own client that doesn’t use PAR.
> >>
> >> So it seems to me that the only scenario that this parameter would
> protect against is a malicious party impersonating a dynamically registered
> client that uses PAR. That wouldn’t apply to Mix-Up, since in that attack
> the attacker uses its own client.
> >>
> >> This client metadata parameter is meant to be something that would
> prevent a malicious actor from controlling the content of the authz request
> parameters, which could be done by crafting the link and tricking a user
> into following it. I mentioned mix-up as an example because the first
> variant of it desribed at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4..4.1
> does something along those lines.
> >>
> >>
> >>
> >> If a client can do PAR, then it can do authorization code grant and
> PKCE, so we’re further limited to scenarios where the attacker does not
> need to be able to redeem the authorization code themselves. What threats
> fall into this category?
> >>
> >> —
> >> Annabelle Backman (she/her)
> >> AWS Identity
> >>
> >>> On Apr 14, 2020, at 2:44 PM, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> >>>
> >>> 
> >>> CAUTION: This email 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-07.txt

[Vittorio Bertocci]

Dear all,
Thanks for all the feedback at the last round. Here’s a new version of the 
draft incorporating your suggestions. Main changes:

-Added the None prohibition in section 2.1 as well
-Incorporated language suggestions from Dominick (and fixed the spelling of his 
last name ;))
-Clarified cases in which identity claims might appear in a JWT AT
-Various typos, formatting issues fixed




On 4/27/20, 11:27, "OAuth on behalf of internet-dra...@ietf.org" 
 wrote:


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   : JSON Web Token (JWT) Profile for OAuth 2.0 Access 
Tokens
Author  : Vittorio Bertocci
Filename: draft-ietf-oauth-access-token-jwt-07.txt
Pages   : 19
Date: 2020-04-27

Abstract:
   This specification defines a profile for issuing OAuth 2.0 access
   tokens in JSON web token (JWT) format.  Authorization servers and
   resource servers from different vendors can leverage this profile to
   issue and consume access tokens in interoperable manner.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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] I-D Action: draft-ietf-oauth-access-token-jwt-07.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   : JSON Web Token (JWT) Profile for OAuth 2.0 Access 
Tokens
Author  : Vittorio Bertocci
Filename: draft-ietf-oauth-access-token-jwt-07.txt
Pages   : 19
Date: 2020-04-27

Abstract:
   This specification defines a profile for issuing OAuth 2.0 access
   tokens in JSON web token (JWT) format.  Authorization servers and
   resource servers from different vendors can leverage this profile to
   issue and consume access tokens in interoperable manner.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Vittorio Bertocci]

Thanks Brian, that appears to have worked!

From: OAuth  on behalf of Brian Campbell 

Date: Monday, April 27, 2020 at 06:26
To: Vittorio Bertocci 
Cc: oauth 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 
2.0 Access Tokens"

This old thread 
https://mailarchive.ietf.org/arch/msg/oauth/1ajE-d3nVOFRGLbwMmPViDhEdqw/ has 
some discussion of working with/around that particular quirk of the htmlizing 
tool.

On Mon, Apr 27, 2020 at 2:34 AM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>>
 wrote:
Thank you for bringing this up Benjamin, you saved me from a long wild goose 
chase!
It' good to know that there's a new rfc format version, but I am a bit worried 
about venturing there given that I am barely managing the v2 as it is __ v3 
still feels pretty experimental, and other than this issue, this spec doesn't 
give a lot of opportunities to take advantage of the new features (SVG etc).
Wondering whether I can find a periphrase to express the same notion without 
triggering the script, e.g. omitting the word section or changing the order.
Thx
V.

On 4/24/20, 19:02, "Benjamin Kaduk" mailto:ka...@mit.edu>> 
wrote:

Just on the xml2rfc bits...

On Wed, Apr 22, 2020 at 07:26:40AM +, Vittorio Bertocci wrote:
>
> > Link to section 4.1.2 of SCIM Core is actually linking to section 4.1.2 
of this doc.
> Oh wow. That’s a feature of XML2RFC,… my source simply says by section 
4.1.2 of SCIM Core  in a  block, and the processor interpret it as an 
internal link. I’ll need to dig on how to prevent that from happening for this 
instance. Good catch!

The short form is "you can't".

You're using the "v2" XML format for xml2rfc, which produces as various
output formats text, pdf, and "htmlized" output.  The "htmlized" output is
called that and not "html" because it's the result of taking the text
output and running a script to turn common constructions in I-Ds and RFCs
into hopefully-useful HTML formatting.  In this case, "Section N" outside
of "Section N of [bracketed-reference]" is assumed to be "Section N of the
current document", and that's all that the htmlization script is going to
give you, since it's not working with the semantic richness of the XML
source.

We do, however, as of fairly recently have a "v3" XML format, which is
capable of producing native HTML output that includes SVG figures and the
other exciting features of "v3 XML".  For an example, see
https://www.ietf.org/id/draft-ietf-tsvwg-datagram-plpmtud-19.html .

I personally haven't done any v2-to-v3 conversions yet (too busy reading to
have time to do much writing), but the FAQ entry for doing so is at

https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-how-do-i-convert-my-xml-fil
.

Hope that helps,

Ben

___
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

[OAUTH-WG] draft-parecki-oauth-v2-1-01 - inconsistencies regarding refresh tokens

[Micah Silverman]

In section 1.5, step 8 in the flow says:

The authorization server authenticates the client and validates the refresh
token, and if valid, issues a new access token (and, optionally, a new
refresh token).

Also, Figure 2, step 8 says:

Access Token & Optional Refresh Token

Whether or not the refresh token is rotated (as defined in section 6),
doesn't the response always include a refresh token?

Since it seems likely that the more common use-case will be refresh token
rotation, perhaps the wording in section 1.5 should lean that way?

Perhaps 1.5, step 8 should say:

The authorization server authenticates the client and validates the refresh
token, and if valid, issues a new access token and a new refresh token (or
uses the same refresh token if certain security requirements are met).

Perhaps Figure 2, step 8 should say:

Access Token & Refresh Token

Best,

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

Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?

[Justin Richer]

I agree that any URI could be used but that it MUST be understood by the AS to 
be local to the AS (and not something that can be impersonated by an attacker). 
I wouldn’t even go so far as RECOMMENDED, but it’s certainly an option.

 — Justin

> On Apr 27, 2020, at 4:41 AM, Filip Skokan  wrote:
> 
> I believe implementers should be free to devise their own URIs and not be 
> locked down to one by the spec, at the same time, and RFC6755 subnamespace 
> would be good for guidance.
> 
> So, I would suggest it be RECOMMENDED to use e.g. 
> `urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also that 
> any URN or URL will do if the circumstances call for it.
> 
> Best,
> Filip
> 
> 
> On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt 
>  > wrote:
> Hi all, 
> 
> another topic from last week’s virtual meeting. 
> 
> Shall there be guidance on the request URI structure? 
> 
> Please state your opinion. 
> 
> thanks in advance, 
> Torsten. 
> ___
> 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] PAR - Guidance on the request URI structure needed?

[Sascha Preibisch]

+1

On Mon, 27 Apr 2020 at 01:42, Filip Skokan  wrote:
>
> I believe implementers should be free to devise their own URIs and not be 
> locked down to one by the spec, at the same time, and RFC6755 subnamespace 
> would be good for guidance.
>
> So, I would suggest it be RECOMMENDED to use e.g. 
> `urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also that 
> any URN or URL will do if the circumstances call for it.
>
> Best,
> Filip
>
>
> On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt 
>  wrote:
>>
>> Hi all,
>>
>> another topic from last week’s virtual meeting.
>>
>> Shall there be guidance on the request URI structure?
>>
>> Please state your opinion.
>>
>> thanks in advance,
>> Torsten.
>> ___
>> 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] A token review of draft-parecki-oauth-v2-1-01

[Brian Campbell]

On Fri, Apr 24, 2020 at 5:48 PM Aaron Parecki  wrote:

> Thanks for the detailed review Brian! I've made many of these edits to the
> draft, but there are still a few things that need some discussion on the
> list. My notes are inline below.
>

Thanks Aaron. I realize there was a lot there. I've followed up on just a
couple of the things below that seemed like they needed a response.


>
>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-6
>>  "  *  _Sender-constrained refresh tokens:_ the authorization server
>>   cryptographically binds the refresh token to a certain client
>>   instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705]."
>> Given the relative immaturity of ways to do this, maybe something more
>> open ended would be appropriate? This reads like token-binding or MTLS are
>> the only ways allowed. I'd think wording that would allow for DPoP or some
>> yet-to-be-defined method would be better here. Also maybe drop the
>> token-binding reference all together (it's long expired and doesn't look
>> like that's gonna change).
>>
>
> I'm generally supportive of something more open ended here. Would that
> also suggest that the corresponding text in the Security BCP be updated as
> well?
>

For some reason, I'd been thinking that this stuff had been changed in the
Security draft. But I was apparently mistaken.  Anyway, yes, I think it
should be updated there as well.



>
>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.7
>> 
>> "Attacker A4 in (#secmodel)"
>> "The use of PKCE is RECOMMENDED to this end."
>> PKCE is required elsewhere so this doesn't seem quite right. Similar
>> comments about text ijn
>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.14
>> that talks as though PKCE might not be there.
>>
>
> I believe this text was included since an extension such as OpenID Connect
> can define other methods of authorization code injection. Also note that
> this same sentence is in the Security BCP so if we update anything here
> they should probably match.
>

I guess my understanding of the intended scope of the two documents was
that they were a little different. Like there's a security profile that
describes a few different ways of achieving something with the tools of
2.0, OIDC and PKCE. While 2.1 is saying PKCE is always required and there
are benefits to that. So the latter doesn't seem to need conditional
language around PKCE or alternatives. Maybe my understanding is flawed
though. Or maybe there's a larger question here about the value/need/cost
of having a lot of duplicative or overlapping content across multiple
documents.

-- 
_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] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Brian Campbell]

This old thread
https://mailarchive.ietf.org/arch/msg/oauth/1ajE-d3nVOFRGLbwMmPViDhEdqw/
has some discussion of working with/around that particular quirk of the
htmlizing tool.

On Mon, Apr 27, 2020 at 2:34 AM Vittorio Bertocci  wrote:

> Thank you for bringing this up Benjamin, you saved me from a long wild
> goose chase!
> It' good to know that there's a new rfc format version, but I am a bit
> worried about venturing there given that I am barely managing the v2 as it
> is __ v3 still feels pretty experimental, and other than this issue, this
> spec doesn't give a lot of opportunities to take advantage of the new
> features (SVG etc).
> Wondering whether I can find a periphrase to express the same notion
> without triggering the script, e.g. omitting the word section or changing
> the order.
> Thx
> V.
>
> On 4/24/20, 19:02, "Benjamin Kaduk"  wrote:
>
> Just on the xml2rfc bits...
>
> On Wed, Apr 22, 2020 at 07:26:40AM +, Vittorio Bertocci wrote:
> >
> > > Link to section 4.1.2 of SCIM Core is actually linking to section
> 4.1.2 of this doc.
> > Oh wow. That’s a feature of XML2RFC,… my source simply says by
> section 4.1.2 of SCIM Core  in a  block, and the processor interpret it
> as an internal link. I’ll need to dig on how to prevent that from happening
> for this instance. Good catch!
>
> The short form is "you can't".
>
> You're using the "v2" XML format for xml2rfc, which produces as various
> output formats text, pdf, and "htmlized" output.  The "htmlized"
> output is
> called that and not "html" because it's the result of taking the text
> output and running a script to turn common constructions in I-Ds and
> RFCs
> into hopefully-useful HTML formatting.  In this case, "Section N"
> outside
> of "Section N of [bracketed-reference]" is assumed to be "Section N of
> the
> current document", and that's all that the htmlization script is going
> to
> give you, since it's not working with the semantic richness of the XML
> source.
>
> We do, however, as of fairly recently have a "v3" XML format, which is
> capable of producing native HTML output that includes SVG figures and
> the
> other exciting features of "v3 XML".  For an example, see
> https://www.ietf.org/id/draft-ietf-tsvwg-datagram-plpmtud-19.html .
>
> I personally haven't done any v2-to-v3 conversions yet (too busy
> reading to
> have time to do much writing), but the FAQ entry for doing so is at
>
> https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-how-do-i-convert-my-xml-fil
> .
>
> Hope that helps,
>
> Ben
>
> ___
> 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] PAR - Guidance on the request URI structure needed?

[Filip Skokan]

I believe implementers should be free to devise their own URIs and not be
locked down to one by the spec, at the same time,
and RFC6755 subnamespace would be good for guidance.

So, I would suggest it be RECOMMENDED to use e.g.
`urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also
that any URN or URL will do if the circumstances call for it.

Best,
*Filip*


On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt  wrote:

> Hi all,
>
> another topic from last week’s virtual meeting.
>
> Shall there be guidance on the request URI structure?
>
> Please state your opinion.
>
> thanks in advance,
> Torsten.
> ___
> 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] PAR - Can AS/client require request object?

[Filip Skokan]

Considering there's going to be a setting that forces clients to use PAR
(other mailinglist thread), then we should rely on the existing
`request_object_signing_alg` presence to indicate a Request Object must be
used (as suggested by this upcoming OIDC Core errata
),
regardless of it being PAR or JAR. I don't see the need for a PAR specific
metadata, for one - implementations wouldn't be easily able to re-use of
existing pipelines, two - yes the contexts differ but do you think clients
will be using both channels at the same time? And even if so, the Request
Object is the same therefore its applicable to both channels the same.

Best,
*Filip Skokan*


On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt  wrote:

> Hi all,
>
> this is one of the topics we quickly flipped through in the virtual
> meeting last week.
>
> I see the following open questions:
> - Can the client require its instances to use request objects only.
> - Are there further requirements on the properties of these objects?
> Signed only, Signed and encrypted, algorithms?
> - Can an AS require ALL clients to use request objects only?
> - Further requirements here as well?
> - Is this tied to PAR or relevant for JAR as well?
>
> In my opinion, client as well as AS should be able to control enforced use
> of request objects.
>
> I could imagine the setting for JAR request objects (“request" parameter)
> and request objects in the PAR context differ, as the first case goes
> through the user’s browser whereas the PAR case goes direct from client to
> AS via a TLS protected channel. I therefore feel the settings should be PAR
> specific.
>
> What do you think?
>
> best regards,
> Torsten.
> ___
> 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] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Vittorio Bertocci]

Thank you for bringing this up Benjamin, you saved me from a long wild goose 
chase!
It' good to know that there's a new rfc format version, but I am a bit worried 
about venturing there given that I am barely managing the v2 as it is __ v3 
still feels pretty experimental, and other than this issue, this spec doesn't 
give a lot of opportunities to take advantage of the new features (SVG etc).  
Wondering whether I can find a periphrase to express the same notion without 
triggering the script, e.g. omitting the word section or changing the order.
Thx
V.

On 4/24/20, 19:02, "Benjamin Kaduk"  wrote:

Just on the xml2rfc bits...

On Wed, Apr 22, 2020 at 07:26:40AM +, Vittorio Bertocci wrote:
> 
> > Link to section 4.1.2 of SCIM Core is actually linking to section 4.1.2 
of this doc.
> Oh wow. That’s a feature of XML2RFC,… my source simply says by section 
4.1.2 of SCIM Core  in a  block, and the processor interpret it as an 
internal link. I’ll need to dig on how to prevent that from happening for this 
instance. Good catch!

The short form is "you can't".

You're using the "v2" XML format for xml2rfc, which produces as various
output formats text, pdf, and "htmlized" output.  The "htmlized" output is
called that and not "html" because it's the result of taking the text
output and running a script to turn common constructions in I-Ds and RFCs
into hopefully-useful HTML formatting.  In this case, "Section N" outside
of "Section N of [bracketed-reference]" is assumed to be "Section N of the
current document", and that's all that the htmlization script is going to
give you, since it's not working with the semantic richness of the XML
source.

We do, however, as of fairly recently have a "v3" XML format, which is
capable of producing native HTML output that includes SVG figures and the
other exciting features of "v3 XML".  For an example, see
https://www.ietf.org/id/draft-ietf-tsvwg-datagram-plpmtud-19.html .

I personally haven't done any v2-to-v3 conversions yet (too busy reading to
have time to do much writing), but the FAQ entry for doing so is at

https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-how-do-i-convert-my-xml-fil
.

Hope that helps,

Ben

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