Re: [OAUTH-WG] Namespacing "type" in RAR

I’d agree with this. I’d probably go even further and suggest the specification simply disallow non-ASCII values - it just seems like a minefield that so many people have unsuccessfully attempted to negotiate, and it is not necessary to force or allow AS implementors (or the rest of the ecosyste

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

An RS is not considered an OAuth 2 client, though there’s enough overlap in the structure that I know several implementations that store RS records in the same table as the client records with a special flag set on them to differentiate. The RS <-> AS communication channel has never really gotte

Re: [OAUTH-WG] Namespacing "type" in RAR

I’m suggesting that API designers avoid using such glyphs in their “type” values if they want to avoid such human-copy errors, like they would need to do for most other strings in their system. If that means they stick to ASCII or put a note on the developer page that says “hey copy and paste th

Re: [OAUTH-WG] Namespacing "type" in RAR

In unicode, a glyph can be represented by more than one code point. When reading the docs and entering a value, the developer will not know which code point the AS intended. Are you suggesting that AS documentation would have the bytes rather than glyphs? Or not use glyphs that have multiple code

Re: [OAUTH-WG] Namespacing "type" in RAR

Right, and I’m saying that all three of those would be DIFFERENT “type” values, because they’re different strings. The fact that when treated as URIs they would be equivalent is irrelevant. Just like “foo”, “Foo”, and “FOO” would be different “type” values, per the spec. Nothing is stopping an A

Re: [OAUTH-WG] Namespacing "type" in RAR

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/v1” > “HTTPS://s

Re: [OAUTH-WG] Namespacing "type" in RAR

The following are the same URI, but are different strings: “https://schema.example.org/v1” “HTTPS://schema.example.org/v1 ” “https://SCHEMA.EXAMPLE.ORG/v1 ” Before comparing them to each other, they must be canonicalized so that they b

Re: [OAUTH-WG] Namespacing "type" in RAR

String comparison works just fine when the strings happen to be URIs, and you aren’t treating them as URIs: “https://schema.example.org/v1” Is different from “https://schema.example.org/v2” And both are different from “https://schema.example.org:443/v1/“ All of these

Re: [OAUTH-WG] Namespacing "type" in RAR

This statement: “compare two strings so that they’re exact” does not work for either Unicode or URIs. A string, and a canonicalized Unicode string are not the same thing. Similar for a URI. I have assumed you understand the canonicalization requirement, but it does not sound like you do. Would yo

Re: [OAUTH-WG] Namespacing "type" in RAR

> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov wrote: > > > > On 21/07/2020 17:47, Justin Richer wrote: >>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov >>> wrote: >>> >>> On 18/07/2020 17:12, Justin Richer wrote: I think publishing supported “type” parameters isn’t a bad idea, an

Re: [OAUTH-WG] Namespacing "type" in RAR

On 21/07/2020 17:47, Justin Richer wrote: >> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov >> mailto:vladi...@connect2id.com>> wrote: >> >> On 18/07/2020 17:12, Justin Richer wrote: >>> I think publishing supported “type” parameters isn’t a bad idea, and it >>> aligns with publishing supported

Re: [OAUTH-WG] Namespacing "type" in RAR

> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov > wrote: > > On 18/07/2020 17:12, Justin Richer wrote: >> I think publishing supported “type” parameters isn’t a bad idea, and it >> aligns with publishing supported scopes and claims in discovery. > If you are a developer, would you like to be

Re: [OAUTH-WG] Namespacing "type" in RAR

If we treat all the strings as just strings, without any special internal format to be specified or detected, then comparing the strings is a well-understood and well-documented process. I also think that we shouldn’t invent anything here, so if there’s a better way to say “compare two strings s

Re: [OAUTH-WG] OAuth WG Interims - Aug/Sep 2020

It is 12:00pm EDT. I sent an updated message with the correct calendar invite. Regards, Rifaat On Tue, Jul 21, 2020 at 9:15 AM Tim Cappalli wrote: > The original message (and calendar invite) said the 8/10 meeting was at > 6am EDT. Is it 6 or 12? > > > > tim > > > > *From: *OAuth > *Date: *W

Re: [OAUTH-WG] OAuth WG Interims - Aug/Sep 2020

The original message (and calendar invite) said the 8/10 meeting was at 6am EDT. Is it 6 or 12? tim From: OAuth Date: Wednesday, July 15, 2020 at 18:05 To: oauth Subject: [OAUTH-WG] OAuth WG Interims - Aug/Sep 2020 All, As you might have noticed, we are starting a series of interim meetings i