I've just published an OAuth JWT Bearer Token
Profilehttp://self-issued.info/docs/draft-jones-oauth-jwt-bearer.html. It
defines a means of using a JSON Web Token (JWT) bearer token to request an
OAuth 2.0 access token. This profile is intentionally strongly based upon the
SAML 2.0 Bearer
Overall this is in good shape. Some points:
Mutual cross-reference between the MAC and Bearer specs might help
people trying to decide what kind of OAuth token to use.
2.3
The parameter name oauth_token is already taken by OAuth 1.0 and
should NOT be re-used here. Suggest changing it to
pls. add a presentation about the security document/considerations to
the agenda
Am 15.03.2011 20:52, schrieb Hannes Tschofenig:
A reminder to send me your presentation request.
On Mar 14, 2011, at 9:13 AM, Hannes Tschofenig wrote:
Hi all,
the IETF meeting in Prague is just around the
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Justin Richer
Mutual cross-reference between the MAC and Bearer specs might help
people trying to decide what kind of OAuth token to use.
Speaking for MAC - over my dead body :-)
EHL
Mutual cross-reference between the MAC and Bearer specs might help
people trying to decide what kind of OAuth token to use.
Speaking for MAC - over my dead body :-)
Now now, that's just not nice. :)
___
OAuth mailing list
OAuth@ietf.org
Many of my comments have probably been covered by other folks on the
list, but I'm going to repeat things along here anyway:
Preamble:
Does this document actually obsolete 5849? Since OAuth2 is explicitly
not backwards compatible, is this WG really making the claim that we're
updating OAuth,
Hi all,
I'm evaluating whether OAuth 2 draft 13 w/ MAC authentication will be suitable
for my situation.
We have an API which will be consumed by approved native apps on mobile
devices. For business reasons I want to ensure that a user cannot use their own
valid access token to make API calls
Steve,
I'm evaluating whether OAuth 2 draft 13 w/ MAC authentication will be
suitable for my situation.
...
I want to ensure that a user cannot use their own valid access token to make
API calls from non-approved clients.
...
I'm aware that determined users could extract the client ID
OAuth 2 intentionally dropped the use of client credentials when making
protected resource requests. This seems to be your main issue.
If you are going to use MAC tokens, one easy solution is to tell your
developers to simply concatenate the client secret with the token secret when
signing the
