It can contain space (%x20) but not tab, carriage return, linefeed, form feed,
vertical tab, backspace, delete (or any other control characters).
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mark Dobrinic
Sent: Tuesday, October 13, 2015 10:43 AM
To: oauth@ie
Hey OAuth group,
While I though I knew this, I was looking closely at the OAuth 2.0 spec
and read that valid values of the client_id are specified as:
VSCHAR = %x20-7E
client-id = *VSCHAR
This means that the client-id may also contain whitespace characters.
Do I get that right?
Thanks for your
Hi Thomas— The UMA Work Group that produced the “RSR” (OAuth Resource Set
Registration) spec has an outstanding issue to fix the BCP190 issue that you
point out. Since it’s a backwards-incompatible change, and we are taking a
semantic versioning approach, we need to plot it out appropriately. We
Centralizing the user auth yes, it doesn't even have to be multiple types of RS
for this to win. It reduces your attack surface and allows your auth stack to
be separate from your app stack are two of the good things. Auth is a
specialized thing and hard to do right, and pulling it down to a m
On 13.10.2015 07:37, Ofer Nave wrote:
>> You do have decisions to make on whether you use symmetric crypto or PK
> there.
>
> That's another thing I was pondering -- simple shared secret, or require
> generated a private/public key pair.
>
> The asymetric form is a little more complicated in term
I think what you’re talking about is reasonable, but I also think that you
don’t need to invent anything. You’re right that these things aren’t defined in
OAuth core itself, but instead they’re defined in companion specs. Most notably
you have:
- JWT (RFC7519): a structured token based on JSO
