and
> HTU values from the RS, as the AS would not know these directly.
>
> — Justin
>
> On Mar 10, 2024, at 4:05 PM, Dick Hardt wrote:
>
> Hey
>
> I was reading over RFC 9449 and was surprised that introspection did not
> take the DPoP header so that the in
Hey
I was reading over RFC 9449 and was surprised that introspection did not
take the DPoP header so that the introspection endpoint could do the check
on the DPoP proof rather than forcing the Resource Server to do it.
t illegitimate requests.
> However, given the rapid development of these features and lack of
> widespread support, I would envision such recommendations to live in a more
> "dynamic" document than an RFC.
>
> Philippe
>
> —
> *Pragmatic Web Security*
> *Security
curity concerns that are beyond the realm of
> OAuth.
>
> Philippe
>
> —
> *Pragmatic Web Security*
> *Security for developers*
> https://pragmaticwebsecurity.com
>
> On 6 Nov 2023, at 15:39, Dick Hardt wrote:
>
> +1 to referring to calling out that cookies / he
to say,
>>>> but we should put them on the list for a future second version of the BCP.
>>>>
>>>> -Daniel
>>>> Am 05.11.23 um 20:03 schrieb Aaron Parecki:
>>>>
>>>> I don't think the Security BCP should incorporate cookie
And Google is not following setting the Referrer-Policy header
https://securityheaders.com/?q=https%3A%2F%2Faccounts.google.com=on
On Sun, Nov 5, 2023 at 11:35 AM Dick Hardt wrote:
> For example, Auth0 has not set any CSP on this endpoint:
>
> https://securityheaders.com/?q=https%3A%2
For example, Auth0 has not set any CSP on this endpoint:
https://securityheaders.com/?q=https%3A%2F%2Fauth0.openai.com
The CSP recommendations are buried in the BCP currently
On Sun, Nov 5, 2023 at 11:28 AM Dick Hardt wrote:
> The cookie and header recommendations I am thinking of wo
o specific architectures,
>> not as a general best practice. For example:
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
>>
>> Aaron
>>
>> On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt wr
entioned in
> the Browser Apps BCP, though only in reference to specific architectures,
> not as a general best practice. For example:
>
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
>
> Aaron
>
> On Sun, Nov 5,
Hey
I was reviewing security on some sites I managed and checked to see if the
recommendations were in the BCP.
I don't see anything around cookies such as httpOnly, sameSite, secure.
I saw some HTTP security header suggestions buried in 4.16
(X-Frame-Options, CSP), but not for
One source of delays could be different chairs that don't have the same
context.
Hard to imagine why the people participating in the oauth group would not
keep participating in a spice group.
I don't have a strong opinion -- but I am surprised by the angst expressed
about having a discussion
I can't help myself to not reply to this ... :)
On Wed, Nov 1, 2023 at 11:18 AM Denis wrote:
>
>
> Bridging the architectural narrative used in the core OAuth framework (AS,
> RS, RO) and in the three roles model
> (Holder, Issuer, Verifier) would not be appropriate.
>
I'm not sure "would not
Link for WIMSE list https://www.ietf.org/mailman/listinfo/wimse
On Mon, Aug 28, 2023 at 11:12 AM Justin Richer wrote:
> Hi all,
>
> Back at IETF116 in Yokohama, Evan Gilman presented information about
> SPIFFE, a workload security platform. At IETF 117 in SF, we presented a set
> of questions
While a breach of a BFF may be as catastrophic as an exfiltration of an
access token, the BFF may also be more secure against a breach.
For example, a BFF could detect a possible compromise by the API usage
pattern becoming unusual to the app, that a RS is not able to detect as the
general usage
I agree we should continue to explore service workers — but it does not
seem that using them is a best current practice — and on that basis and
assuming that is correct, I think the SW approach should be dropped from
the document.
On Mon, Aug 28, 2023 at 8:31 AM Yannick Majoros wrote:
> I think
essive information disclosure.
>
> Regards
> Jaimandeep Singh
>
> On Sat, 26 Aug, 2023, 8:27 pm Dick Hardt, wrote:
>
>> Jaimandeep: Do I understand your objection to adoption is that providing
>> a resource discovery endpoint increases the attack surface as an
>> a
Jaimandeep: Do I understand your objection to adoption is that providing a
resource discovery endpoint increases the attack surface as an
attacker gains knowledge about the resource?
If I understand that correctly, then you are suggesting security through
obscurity.
As mentioned by Aaron, there
I support adoption.
On Wed, Aug 23, 2023 at 12:02 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us
Philippe: thanks for investigating each of the links I provided. I had
mistakenly assumed that the SW would be managing the entire OAuth
interaction per the recommendation.
Yannick: thank you for sharing your own experience and views.
It seems that the SW recommendation is aspirational rather
o having this as one of the
> “recommended approaches” in an RFC.
>
> Hope this helps
>
> Philippe
>
>
> On 11 Aug 2023, at 02:56, Dick Hardt wrote:
>
>
> Philippe: would you expand on your comment:
>
> On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck <
&
Philippe: would you expand on your comment:
On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:
- Remove unproven and overly complicated solutions (i.e., the service
worker approach)
A quick Google on oauth service workers returned a number of articles
e site to verify the identity.
>
>
> Sorry for that stupid example but I'm really not able to explain the issue
> in another way anymore :(
> On 8/11/23 00:02, Dick Hardt wrote:
>
> This sentence does not make sense to me "which AS is AUTHORIZED at which
> RS acti
try to think from a different
> perspective:
>
> As authorization protocol, how can it not let the user decide which AS is
> AUTHORIZED at which RS acting as the user?
>
>
> On 8/10/23 23:28, Dick Hardt wrote:
>
> "auth providers" is an extremely confusing term.
"auth providers" is an extremely confusing term.
OAuth has no involvement in the content an RS provides the client -- the AS
only provides authorization to access the content at the RS.
It is common that the AS and RS are the same entity, but the protocol is
designed to have a separation of
Per https://openid.net/specs/openid-connect-core-1_0.html
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
protocol. It enables Clients to verify the identity of the End-User based
on the authentication performed by an Authorization Server, as well as to
obtain basic profile
I support adoption
On Sat, Jul 29, 2023 at 12:25 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is an official call for adoption for the *SD-JWT-based Verifiable
> Credentials *draft discussed in SF.
> https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/
>
> Please, reply on the mailing
d other four are prototype (and
> given one of those is SecureKey and another one is Gen Digital (ex. Secure
> Key), that relationship should probably be clarified).
>
>
>
> Best,
>
> Kristina
>
>
>
> *From:* OAuth *On Behalf Of * Dick Hardt
> *Sent:* We
I just noticed this doc is up for publication.
I did a quick search on the last call discussion, and did not see any +1s,
nor any review by any of the active members of the OAuth WG.
This is very surprising given the functional overlap with OAuth 2.0, and
the years of deployment experience in
I approve this request.
On Wed, Apr 5, 2023 at 8:47 AM David Dong via RT <
drafts-expert-review-comm...@iana.org> wrote:
> Dear Michael, Nat, John and Dick (cc: oauth WG / review mailing list),
>
> As the designated experts for the OAuth Authorization Server Metadata
> registry, can you review
I support adoption by the WG
On Fri, Jan 27, 2023 at 8:51 AM Mike Jones wrote:
> Given that the draft is now being used, I support working group adoption.
>
>
>
> I’d also like to request time in Yokohama to talk about the draft.
>
>
>
>
On Thu, Dec 15, 2022 at 12:39 PM Tobias Looker
wrote:
> > Would be good to see tos_uri and policy_uri (personally, I'm
> disappointed in the name policy_uri as policy is a much broader context
> than privacy -- but that discussion is over =)
>
> Ok so to be clear you are suggesting we update the
Mw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4AhRuXZCnU
1. I see the value of client discovery for registered clients as well as
for registering clients. For example, the client may be registered at a
number of ASes, and a discovery document lets the client update its
information once at its discovery endpoint rather than having to
manually update the
+1
On Thu, Jul 28, 2022 at 5:17 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is a call for adoption for the *SD-JWT* document
> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/
>
> Please, provide your feedback on the mailing list by *August 12th*.
>
> Regards,
>
> The official IANA registration of “nonce” says:
>
>
> Value used to associate a Client session with an ID Token
>
>
> Does this matter? If not, does it matter if some other spec defines a “htm”
> claim with different meaning?
>
>
> On 16 Jun 2022, at 20:50,
Registering the names provides clarity on use and avoids confusion on the
meaning of a claim — ie two specs won’t have conflicting definitions of
“htm”
On Thu, Jun 16, 2022 at 10:20 AM Warren Parad wrote:
> I think the registration really helps with discovery, especially as an
> implementer.
Best practices according to whom?
This list, and documents such as:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics
Wouldn't the concerns of section 6 of your draft better be parts of a
follow-up or addendum to rfc-6749?
OAuth 2.1 has no normative changes over OAuth
Hi Rifaat
I'm suspecting there was a conversation on changing the name to
multi-subject JWT. Would you provide a pointer or short summary?
I find the name concerning as I am looking at a very different concept that
would also be considered a multi-subject JWT.
My use case is where user
Given you sent the initial review a few months ago, let’s not hold up the
process and move forward.
On Thu, Jan 6, 2022 at 7:23 PM Amanda Baber via RT <
drafts-expert-review-comm...@iana.org> wrote:
> Hi,
>
> On Fri Jan 07 01:12:36 2022, dick.ha...@gmail.com wrote:
> > Unfortunately I don’t know
Unfortunately I don’t know what the approval process is — I don’t feel I
need to discuss or review with the others — the IANA registration is pretty
straightforward and I have not heard any controversy about it
I recall at least 2 of the other experts are aligned on the underlying spec.
On
TTP effort that
> has recently been chartered to solve similar encapsulation problems in
> HTTP.
>
> - Justin
>
> From: OAuth [oauth-boun...@ietf.org] on behalf of Dick Hardt [
> dick.ha...@gmail.com]
> Sent: Friday, October 22, 2021 6:
I have a use case for a self contained request that can be
independently verified by multiple parties. IE, not just have PoP at HTTP
endpoint, but by components doing processing further down the line. It also
provides non-repudiation.
For example, a JWT that is sent as an HTTP payload includes
Thanks for the feedback Brian. We have struggled in how to concisely
describe credentialed clients.
"identifying a client" can be interpreted a number of ways.
The intent is that the AS knows a credentialed client is the same client it
previously interacted with, but that the AS can not assume
inline
On Fri, Oct 8, 2021 at 2:00 PM Richard Backman, Annabelle <
richa...@amazon.com> wrote:
> IE, if the success of HTTP Signing is tied to the OAuth WG adopting the
> draft, then Mike's arguments about the WG already doing this work is valid.
>
>
> It's not the success of HTTP Message
On Fri, Oct 8, 2021 at 12:39 PM Richard Backman, Annabelle <
richa...@amazon.com> wrote:
>
> Blocking WG development of an OAuth 2.0 profile of Message Signatures
> behind widespread deployment of Message Signatures risks creating a
> deadlock where the WG is waiting for implementations from
>
> HTTP Message Signing exists, people are implementing it and using it.
Token Binding existed as well.
HTTP Message Signing is not yet an RFC, and in my opinion it only makes
sense for OAuth to build on top of it if it is successful with lots of
interoperable deployments.
ᐧ
On Fri, Oct 8,
fect time to be able to
> influence the draft if needed, rather than wait for it to be finalized and
> then have to find a less-than-ideal workaround for something unforeseen.
>
> Aaron
>
> On Wed, Oct 6, 2021 at 2:25 PM Dick Hardt wrote:
>
>> I meant it is not yet ado
bout a year ago. I would not have suggested
> we depend on it for a document within this WG otherwise.
>
> — Justin
>
> On Oct 6, 2021, at 5:08 PM, Dick Hardt wrote:
>
> I am not supportive of adoption of this document at this time.
>
> I am supportive of the concepts in t
I am not supportive of adoption of this document at this time.
I am supportive of the concepts in the document. Building upon existing,
widely used, proven security mechanisms gives us better security.
HTTP Sig looks very promising, but it has not been adopted as a draft, and
as far as I know,
m the responses to this thread so far, I think the answer is
> no.
>
>
>
>
>
> Thanks for comment, David,
>
>
>
> Yeah, maybe it's wise to have AS anyway for better extensibility.
>
>
>
>
>
> Toshio Ito
>
>
>
> *From:* David Waite
&
> So, we are seeking a solution that is more in application layer.
>
>
>
>
>
> Toshio Ito
>
>
>
> *From:* Dick Hardt
> *Sent:* Friday, October 1, 2021 12:53 PM
> *To:* ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ)
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] self-is
So, if we do standardize self-issued access tokens, maybe OAUTH WG is not
> the
>
> right venue. Maybe HTTPBIS or HTTPAPI WGs?
>
>
>
>
>
> Toshio Ito
>
>
>
> *From:* Dick Hardt
> *Sent:* Wednesday, September 29, 2021 3:06 PM
> *To:* ito toshio(伊藤 俊夫 ○ＲＤ
If the client is sending a self-signed JWT to the RS, you essentially are
just authenticating directly to the RS. Not really OAuth as the RS has not
delegated authorization authority to the AS.
If the client sends a self-signed JWT (a PAR) to the AS, and gets back an
access token to present to
Hey Emond
The access token represents the authorization to access the resource(s) --
it does not represent the authorization to manipulate tokens. The client
credentials are used for token management. While your implementation may be
ok with using the access token to revoke itself, it is not the
As I said in the meeting, I think this is an interesting idea that is worth
exploring.
I don’t think we need to resolve this for WG adoption of the document.
On Sat, May 15, 2021 at 8:36 AM Filip Skokan wrote:
> Hello Vittorio, Brian, everyone
>
> This is a followup to my feedback in the TMI
ne with the BFF acronym since it's common
>> in the software development world already. If anything, the TMI acronym is
>> the least strong of the two as it's missing a letter from the full name of
>> the draft.
>>
>> Aaron
>>
>>
>>
>>
>
t's common
> in the software development world already. If anything, the TMI acronym is
> the least strong of the two as it's missing a letter from the full name of
> the draft.
>
> Aaron
>
>
>
>
> On Tue, May 4, 2021 at 7:40 AM Dick Hardt wrote:
>
>> I'm supportiv
I'm supportive -- but am concerned with the BFF acronym.
ᐧ
On Mon, May 3, 2021 at 3:00 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is a call for adoption for the *Token Mediating and Session
> Information Backend for Frontend* as a WG document:
>
Thank you very much for your detailed feedback Vittorio!
ᐧ
On Tue, Dec 8, 2020 at 3:22 PM wrote:
> Dear authors,
>
> It took ages but I finally managed to go thru a full review of the current
> OAuth2.1 draft. Apologies for the delay.
>
> Metacomments:
>
>- The VAST majority of the comments
+1
ᐧ
On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is a call for adoption for the following AS Issuer Identifier in
> Authorization Response as a WG document:
>
> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
>
> Please, provide your
I have 2 suggestions for the draft that I beleive address the issues Denis
is bringing up:
1) call out that a DPoP proof can only be used once, and a new DPoP proof
is needed for every API call. Apologies if that is in the text -- but I
could not find it doing a skim over the document.
2)
m-2020-oauth-16-202011301200-01
> and here:
> https://codimd.ietf.org/notes-ietf-interim-2020-oauth-16-oauth?view
>
> Thanks to *Dick Hardt* for taking these notes.
>
> Regards,
> Rifaat & Hannes
> ___
> OAuth mailing list
&
Pushing this to the top of the stack in case there is interest in
separating the binding mechanism from the RT / AT so that existing RTs /
ATs can be used.
ᐧ
On Fri, Nov 6, 2020 at 2:12 PM Dick Hardt wrote:
> Hello
>
> After reviewing the DPoP spec, and reflecting on implementatio
Since there is no security boundary between profiles, the profile is just
passed as a parameter to APIs rather than have it in the access token.
ᐧ
On Thu, Nov 12, 2020 at 1:31 PM Jeff Craig wrote:
> Hello OAuth WG,
>
> I am currently doing some research on APIs that have a Profile concept,
>
Hello
After reviewing the DPoP spec, and reflecting on implementations I have
worked with, I wanted to see if there was interest in a DPoP Binding JWT.
The use case is to enable existing deployments to add support for DPoP
without having to replace their existing refresh token and access tokens,
s signed using the expected certificate. Web2app
> flows are trickier, on both iOS and on Android. There were lengthy
> discussions on at least the Android case at OAuth Security Workshop this
> year (recordings available).
>
> Joseph
>
>
> On 20 Oct 2020, at 00:09, Dick Hardt wro
e
> language that could be perceived as prohibiting it) but haven't gotten to
> that item on the editing todo list yet.
>
>
>
>
> On Wed, Oct 28, 2020 at 2:46 PM Dick Hardt wrote:
>
>> Hello
>>
>> I was reviewing the latest DPoP draft[1] and saw numerous
Hello
I was reviewing the latest DPoP draft[1] and saw numerous mentions of using
a DPoP proof for refreshing an access token, but no explicit description of
how to do that, nor an example. Was this intentional?
Perhaps a new section "Refreshing an Access Token"?
Additionally, I can imagine
Hey Vittorio
(cc'ing OAuth list as this was brought up in the office hours today)
https://developer.android.com/training/app-links
An app is the default handler and the developer has verified ownership of
the HTTPS URL. While a user can override the app being the default handler
in the system
Please join!
ᐧ
On Fri, Oct 9, 2020 at 10:17 AM Jeff Hodges wrote:
> > The Web Authorization Protocol (oauth) WG will hold
> > a virtual interim meeting on 2020-11-02 from 12:00 to 13:00
> America/Toronto (17:00 to 18:00 UTC).
> >
> > Agenda:
> > 1.High level overview of anti-tracking and
Janak, thanks for the clarification.
A constraint of the OAuth 2.1 draft is that it adds no new features beyond
what has already been standardised and deployed.
While I am a fan of JSON, supporting both application/x-www-form-urlencoded
and application/json will negatively impact
That was a lot of words Brian. What is the "tl;dr:"? (I read it, but I'm
not sure where you landed given your last sentence)
ᐧ
On Tue, Sep 15, 2020 at 3:16 PM Brian Campbell wrote:
> Sorry for the slow reply to this one, Neil. It's gotten me thinking a bit
> and it took some time to gather my
+1
KISS
ᐧ
On Tue, Sep 8, 2020 at 3:55 PM John Bradley wrote:
> +1
> On 9/8/2020 7:45 PM, Brian Campbell wrote:
>
> Indeed there are cases, as you point out, where the key might be knowable
> to the server via some other means, which makes the "jwk" header in the
> DPoP proof not strictly
Denis
The objective of this document is to standardize the token the AS shares
with the RS. It is not to standardize how the client can read the token.
Just because the user is using the client, that does not mean the user
wants the client to see any claims about themselves. Letting the client
Endpoint. That’s why it’s preferable to not use one at
>> all and instead directly have the Resource understand the Access Token.
>> One way of doing this is the JWT Access Token spec. There are plenty of
>> others.
>>
>>
>>
>> The downsides of using an
gt; Since parts of the request content, e.g. the "code_challenge"
>parameter value, is unique to a certain authorization request,
> the client SHOULD use the "request_uri" only once.
>
> I also would move this text to section 4.
>
> > On 27. Aug 2020,
If this implication is not acceptable, implementers can
> use other means to carry
> access token data, e.g. directly transferring the data needed by the
> RS within the access token.
>
> On Aug 27, 2020, at 12:15 PM, Dick Hardt wrote:
>
> Here is a crisper revision.
>
> Impl
any constraint on the kind of applications OAuth can
> be used for. I don’t see how this governs the protocol design.
>
> > On 28. Aug 2020, at 15:29, Dick Hardt wrote:
> >
> > The driver in my opinion for first-party use of OAuth is to separate the
> trust domains so that the
The driver in my opinion for first-party use of OAuth is to separate the
trust domains so that the application is scoped in what it can do vs an
application that has full access to all resources. I agree that third-party
can indicate that internal use does not apply. How about the following?
ng this is the JWT Access Token spec. There are plenty of others.
>
> The downsides of using an Introspection Endpoint should be described in
> the Privacy Considerations section.
>
> -- Mike
>
> From: OAuth On Behalf Of Di
twice and continue the session as appropriate.
>
> None of this is in conflict with “one time use”, in my view, since you’re
> actively detecting the session and source of the value.
>
> — Justin
>
> On Aug 26, 2020, at 6:16 PM, Dick Hardt wrote:
>
> I think one-time use
I think one-time use may be overly restrictive, and I don't think it is the
property that we actually want.
Give the request URI is in a redirect from the browser, there is a good
chance of a race condition where the same browser request is made more than
once, for example, while the browser is
On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt wrote:
> Hi Denis,
>
> > On 25. Aug 2020, at 16:55, Denis wrote:
>
> > The fact that the AS will know exactly when the introspection call has
> been made and thus be able to make sure which client
> > has attempted perform an access to that RS
Are either of these happening tomorrow? If so, what is the WebEx link?
Thanks!
ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I'm supportive of this work.
It is not clear that it is in the charter of the OAuth WG.
On Mon, Aug 10, 2020 at 9:01 AM Filip Skokan wrote:
> Hi Neil,
>
> I'm interested in seeing both AES SIV and ECDH-1PU for JOSE. Not sure how
> to go about it tho since JOSE is a concluded WG.
>
> Out of
In the PAR meeting today, Denis requested there be a privacy considerations
section in PAR. I don't think there is anything specific in PAR that would
change the privacy considerations of OAuth, and am checking if there is WG
interest, and consensus, on including a Privacy Considerations section
Karsten / Christian: thank you for reviewing the draft and all of your
feedback. Greatly appreciated!
Responses inline ... if no comment, I (or another author) will have to
review to respond.
On Thu, Aug 6, 2020 at 3:48 AM Karsten Meyer zu Selhausen <
karsten.meyerzuselhau...@hackmanit.de>
Dev’s now need to read 20 standards to get OAuth2 basics...
> and that’s a barrier to entry.
>
> --
> Jim Manico
> @Manicode
>
> On Jul 30, 2020, at 3:21 PM, Dick Hardt wrote:
>
>
> One of the constraints of the OAuth 2.1 document that aligned the WG was
> it would h
One of the constraints of the OAuth 2.1 document that aligned the WG was it
would have no new features.
I'd recommend a separate document for the cookie bearer token feature.
ᐧ
On Thu, Jul 30, 2020 at 12:15 PM Jim Manico wrote:
> Yea to cookie configuration suggestions!
>
> I suggest
any requirements on
> canonicalization for these values.
>
> — Justin
>
> On Jul 21, 2020, at 1:03 PM, Dick Hardt wrote:
>
>
> The following are the same URI, but are different strings:
>
> “https://schema.example.org/v1”
> “HTTPS://schema.example.org/v1
An explanation of the issues in Unicode can be found here:
https://en.wikipedia.org/wiki/Unicode_equivalence#Character_duplication
On Tue, Jul 21, 2020 at 10:03 AM Dick Hardt wrote:
>
> The following are the same URI, but are different strings:
>
> “https://schema.example.org/
and not required for the RAR spec. I’m against requiring
> the value to be a URI and against requiring the AS to process that URI *as
> a URI* at runtime. Anything that an AS wants to do with the “type” value,
> including providing additional tooling and validation, is up to the AS and
> outside of
value. You brought that up and then described the process that the AS would
> take to do so. I have said from the start that the use of a URI is for name
> spacing and not for addressing content to be fetched, so I’m confused why
> you think I intend otherwise.
>
> — Justin
>
>
aller ecosystem. And this is yet another
> reason that we define “type” as being a string to be interpreted and
> understood by the AS — so that an AS that wants to work this way can do so.
>
> — Justin
>
> PS: thanks for pointing out the error in the example in XYZ, I’ll fix tha
etf.org/html/rfc7519#section-4.2
>
> What I’m proposing is that if you think it’s going to be a general-purpose
> type name, then we recommend you use a URI as your string. And beyond that,
> that’s it. It’s up to the AS to figure out what to do with it, and RAR
> stays out of it.
>
Hey Justin, glad to see that you have aligned with the latest XAuth draft
on a type property being required.
I like the idea that the value of the type property is fully defined by the
AS, which could delegate it to a common URI for reuse. This gets GNAP out
of specifying access requests, and
+1
On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is a *call for adoption* for the following *OAuth 2.1* document as a
> WG document:
> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html
>
> Please, provide your feedback on the mailing list by *July 29th.*
>
>
I don't know of any discussion for client secret rotation.
Another way to solve your problem could be to raise it up a layer. Admin B
generates a one time use URL that is sent to Admin A. Admin A visits the
URI and obtains the client_id and client_secret.
On Mon, Jul 13, 2020 at 2:35 PM
Thanks Sascha and Vladimir for the feedback!
Sascha: did you have a concern with the document being adopted by the WG?
ᐧ
On Tue, Jul 7, 2020 at 4:04 PM Sascha Preibisch
wrote:
> Hi all!
>
> Here is the rest of my feedback. At the end I also included a list of
> typos and the summary of
Aaron, Torsten, and I -- with some help from Daniel -- have created a new
version of draft-pareck-oauth-v2-1. I think we are ready for a WG adoption
call (assuming the updated charter).
Here is the doc:
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-03
Here is a link to the diff from -02:
1 - 100 of 408 matches
Mail list logo
