James, this is a very good question particularly since we have a working group
item in progress that provides security properties beyond bearer tokens.
Ciao
Hannes
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of ext
Manger, James H
Sent: Thursday, June 06, 2013 7:06 A
BEARER tokens dominate OAuth 2 deployments today, but OAuth 2 is deliberately
extensible to support other sorts of credentials (eg MAC authentication).
Why is draft-ietf-oauth-dyn-reg hardwired to only support BEARER tokens?
1.3. “Registration Tokens and Credentials” says:
“The Initial Access
Your “first part” where a developer gets an initial token sounds like a task a
developer does using only a standard web browser, knowing their developer
password. There is no OAuth here; there is no app interacting (just a human at
a browser).
Perhaps I should not have jumped into this thread a
Tim Bray wrote:
> FWIW, I just read the spec through with fresh eyes, and I found the
> explanation of the workflow in 1.4.2 very useful.
>
> - A developer manually registers and then is able to request “Initial tokens”
> tokens for a dynamic-app-registration-scope,
> - you use that “Initial t
Thanks a lot Axel!!
Regards
Antonio
On Jun 5, 2013, at 3:37 PM,
mailto:axel.nenn...@telekom.de>> wrote:
Antonio,
Please have a look at this
https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#104
The \r\n is the important.
Please make sure you have
Also, it's the JOSE working group, not OAuth, that's working on JWS.
I've CC'd that group on this reply, further discussion (if needed)
should probably take place there.
-- Justin
On 06/05/2013 09:37 AM, axel.nenn...@telekom.de wrote:
Antonio,
Please have a look at this
https://code.googl
Antonio,
Please have a look at this
https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#104
The \r\n is the important.
Please make sure you have this byte representation of the payload.
The following octet sequence contains the UTF-8 representation of t
Hi *,
while testing my encoding routine against JWS I spot a difference between my
encoding and the one in the spec.
More specifically I am referring to Appendix A.1.1 [0] of the JWS spec.
Now it could easily be that the library I wrote is wrong but it works fine with
the encoding in the JWT sp
We are not changing current OAuth Semantics. Scopes are per AS and might
apply to different API. The AS needs to sort out its scope name collision
policy otherwise it will be a problem at the authorization endpoint when they
request scopes anyway. Scope is unfortunately already overloade
