Hi Bill,
I believe you are misreading the document. In draft-ietf-oauth-v2-http-mac the
client still uses the MAC when it accesses a protected resource.
The only place where the JWT comes into the picture is with the description of
the access token. This matters from a key distribution point o
Hi Mike,
when I worked on the MAC specification I noticed that the JWT does not have a
claim for the scope. I believe that this would be needed to allow the resource
server to verify whether the scope the authorization server authorized is
indeed what the client is asking for.
Ciao
Hannes
_
Hi Mike, Hi Justin,
when I looked at the JWT and the draft-richer-oauth-introspection documents I
noticed that the two are not aligned (neither from the fields that are
supported nor from the way how the fields are defined).
IMHO draft-richer-oauth-introspection must not define new elements
Hi Hannes,
apologies if I do the same question again but there is still one point that is
a little obscure to me.
As long I did understand the situation for MAC is the following one.
The communication between the client and the authentication server must be
https but this is not true for the c
I'm actually advocating that we change MAC to be a JWT extension.
From: Hannes Tschofenig
To: William Mills
Cc: Hannes Tschofenig ; "oauth@ietf.org"
Sent: Thursday, February 28, 2013 2:28 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-0
The good thing about having two fields is that they map to the two
different parameter names directly. The trouble is that you could get in
a situation where a client can't actually do anything, say if you
register response type "token" and grant type "authorization_code". With
a table like the
While scope is one method that a AS could communicate authorization to a RS, it
is not the only or perhaps even the most likely one.
Using scope requires a relatively tight binding between the RS and AS, UMA
uses a different mechanism that describes finer grained operations.
The AS may include
Are you advocating TWO systems? That seems like a bad choice.
I would rather fix scope than go to a two system approach.
Phil
Sent from my phone.
On 2013-02-28, at 8:17, John Bradley wrote:
> While scope is one method that a AS could communicate authorization to a RS,
> it is not the only o
Personally I am starting to feel strongly that access tokens should be highly
contextual and therefore tightly bound to specific resources.
It seems to me trust will get incredibly complex if we start federating access
tokens. My belief is that uma needs to still chain to local authorization
s
I think John's point was more that scope is something rather specific to an
OAuth access token and, while JWT is can be used to represent an access
token, it's not the only application of JWT. The 'standard' claims in JWT
are those that are believed (right or wrong) to be widely applicable across
d
Hi Hannes
On 27/02/13 08:54, Hannes Tschofenig wrote:
Hi Sergey,
good that this issue got clarified.
Regarding:
By the way, should the server be able to enforce the use of MAC as opposed to
having a client preferring it with its audience info ? If the client does not
understand it then it
Hannes,
The main issue here is that JWT has been built to be used for things
other than OAuth tokens (assertions, for instance), and that the
introspection endpoint is very specifically tied to OAuth. At Torsten's
suggestion, I've tried to align the output of the introspection endpoint
to the
Yes, defining scope in JWT is the wrong place. JWT needs to stick to the
security claims needed to process JWT.
I also don't know how far you get requiring a specific authorization format for
JWT, some AS will wan to use a opaque reference, some might want to use a user
claim or role claim, o
Hi Hannes
On 27/02/13 08:46, Hannes Tschofenig wrote:
Hi Sergey,
thanks for your input.
On Feb 26, 2013, at 2:36 PM, Sergey Beryozkin wrote:
Hi Hannes
On 25/02/13 12:46, Hannes Tschofenig wrote:
Hi all,
I just submitted an updated version of the draft-ietf-oauth-v2-http-mac-03.txt.
It de
Hi
On 28/02/13 13:14, William Mills wrote:
I'm actually advocating that we change MAC to be a JWT extension.
IMHO, having a simpler option, plus, going forward, a possible JWT
profile (client to RS path) would work better -
Why would JWT completely take over ? May be it should be possible inde
I am not advocating anything, only sting what people are doing now.
How authorization is communicated between the AS and RS via a token that is
opaque to the client is out of scope fro OAuth core, it might be magic pixy
dust.
This has lead to a number of ways people are doing it.
JWT along wit
What I don't quite get is what exactly would be presented and processed
at each step. Who needs to know what piece? We don't want to have to
push everything into JSON for the signing to take place (that much is
clear), and we don't want the client to be pushing the MAC secret to the
RS every ti
The communication between AS and RS is not direct it is through the client in
this case. If TLS covers all the connections and is sufficient you probably
don't need MAC:)
If you were to send the symmetric key in the JWT unencrypted than there is no
real point in signing anything as any one in
Am I missing something. JWT is firstly an oauth spec. Otherwise why isnt it in
jose wg?
Phil
Sent from my phone.
On 2013-02-28, at 8:44, Brian Campbell wrote:
> I think John's point was more that scope is something rather specific to an
> OAuth access token and, while JWT is can be used to r
Are you saying jwt is not an access token type?
Phil
Sent from my phone.
On 2013-02-28, at 8:58, John Bradley wrote:
> Yes, defining scope in JWT is the wrong place. JWT needs to stick to the
> security claims needed to process JWT.
>
> I also don't know how far you get requiring a specifi
What people are doing now is often issuing saml like assertions. Thats not
necessarily indicating intent. It just indicates transition.
Phil
Sent from my phone.
On 2013-02-28, at 9:07, John Bradley wrote:
> I am not advocating anything, only sting what people are doing now.
>
> How authoriz
On 28/02/13 17:04, Sergey Beryozkin wrote:
Hi
On 28/02/13 13:14, William Mills wrote:
I'm actually advocating that we change MAC to be a JWT extension.
IMHO, having a simpler option, plus, going forward, a possible JWT
profile (client to RS path) would work better -
Why would JWT completely ta
Yes IETF WG politics:)
Should JWT and JOSE be together ? Through a number of twists and turns they
are not, lets not go there.
But to the point a number of us have made JWT is used in OAuth for more than
access tokens.
Currently it's only use in OAuth is in the JWT assertions profile that h
JWT is an assertion( I am probably going to regret using that word).
It is used in openID connect for id_tokens, it is used in OAuth for Assertion
grant types and authentication of the client to the token endpoint.
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
JSON Web Token (JWT) Be
1) AS issues JWT + secret to client.
2) Client decides to access resource, creates the JWT MAC JSON object which
contains stuff about the signature and the signature itself.
3) client appends that base64 encoded thing to the JWT
1) Server gets a JWTMAC token, takes apart the JWT part to get the s
The JWT replaces the oauth_token data element in the old MAC stuff. I just
want to take all the other oauth_* variables and stuff them in a separate JSON
object and completely kill the "fun with sorting variables" when the oauth_*
things can be carried in the query string or header or post body
OK, so it still runs the signature over HTTP elements (query, url,
headers, etc) but all of the structured components are *communicated*
via a JWT/JOSE structure. That makes sense to me, on the surface at least.
-- Justin
On 02/28/2013 12:43 PM, William Mills wrote:
1) AS issues JWT + secre
I guess we first have to agree whether there is a security benefit of
communicating the scope from the AS to the RS (in a way that it cannot
be modified by the client or any other party).
The scope indicates permissions (for example, whether the resource owner
allowed read access to a certain
Adding my 2 cents ...
I am looking to use JWT as the structure for my access tokens, and will likely
profile it to look just like an id_token, plus the scope claim which triggered
this thread :-)
I am also looking at JWT as a grant type.
I am also looking into federating my access tokens (one
On 28/02/13 17:49, William Mills wrote:
The JWT replaces the oauth_token data element in the old MAC stuff. I
just want to take all the other oauth_* variables and stuff them in a
separate JSON object and completely kill the "fun with sorting
variables" when the oauth_* things can be carried in t
I certainly hope so.
From: Sergey Beryozkin
To: William Mills
Cc: "oauth@ietf.org"
Sent: Thursday, February 28, 2013 10:02 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
On 28/02/13 17:49, William Mills wrote:
> The JWT replaces
JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
Note the title says "for OAuth2"
Sorry. Couldn't resist.
Phil
Sent from my phone.
On 2013-02-28, at 9:40, John Bradley wrote:
> JWT is an assertion( I am probably going to regret using that word).
>
> It is used in openID connect for
Yes. That is my understanding.
Phil
Sent from my phone.
On 2013-02-28, at 9:49, Justin Richer wrote:
> OK, so it still runs the signature over HTTP elements (query, url, headers,
> etc) but all of the structured components are *communicated* via a JWT/JOSE
> structure. That makes sense to m
Yes the title likely adds to the confusion given that the bearer tokens are not
access tokens.
Things as separate from OAuth as the Firefox browerID spec use JWS signed JWTs.
The bearer token profiles for OAuth 2 are for OAuth2.
The JSON Web Token (JWT) spec did not start in OAuth and is not
I'm not sure anyone really "picked" the titles for the bearer token
profiles. They just kind of evolved. And evolved in funny ways especially
when client authn to the AS was added.
You won't hear me argue that the titles are "good" and this is not the
first time there's been confusion about what t
Brian, I think you're conflating two things (and John might be, too). On
the one hand, we've got the JWT document, which talks about what goes
into the token itself. This can be used as an assertion, as an access
token, as a floor wax / dessert topping. JWT doesn't really care, and
this is real
Hi Brian, a few thoughts from somebody outside of the WG ...
As a newcomer to OAuth last year, I was initially confused by the titles. It
was confusing because we have SAML bearer *assertions* and JWT bearer *tokens*
... and as John just (begrudgingly) stated in this thread, the JWT is being
u
Dear OAuth WG and Chairs,
Can somebody please comment the Certicom's disclosure below? If the purpose of
this disclosure is to inform us that JWT can be potentially a subject of
royalties and other possible legal actions, the value of adopting JWT in the
scope of OAuth 2.0 IETF standard would d
To be fair, I think it was Phil who first conflated the things :) I just
picked up the ball and ran with it. But you are right, I did kind of hijack
the thread which was originally about if a scope claim should be defined in
draft-ietf-oauth-json-web-token. I'd say no but I can see how an argument
I do agree that a WG profile of a JWT-structured access token could lend
itself to interoperability and ultimately be a useful thing. But you are
right that there already are many implementations out there in the wild
(heck, I've written one myself) and that might make it difficult to
standardize o
I believe that a "scope" claim should be defined by a particular profile or
profiles that use JWT in a way that needs it, since it's not of general
applicability. The JSON Web Token Claims Registry
(http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-9.1) is
defined exactly f
Agreed profiling needs to happen for access tokens someplace. In the MAC spec
is probably not the best place if the claims are used outside of MAC as well.
There is a separate issue once we get to that profile about scope. I don't
know many RS that do a 1 to 1 mapping of scope at the AS. No
On 02/28/2013 08:21 PM, Oleg Gryb wrote:
> Dear OAuth WG and Chairs,
>
> Can somebody please comment the Certicom's disclosure below? If the
> purpose of this disclosure is to inform us that JWT can be potentially
> a subject of royalties and other possible legal actions, the value of
> adopting JW
SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization
Grants
JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
Assertion Framework for OAuth 2.0
a bit wordy, but does get the point across IMO
- prateek
I'm not sure anyone really "picked" the titles for t
I believe that depending on the resource server that scope is important for
both the security layers and application function layers. For example, an
application may wish to use scope as a set of entitlements. Does client have
entitlement "readProfile".
It makes no sense to me to have a scope
Thanks Prateek. I like it and I think wordy might be the way to go here.
On Thu, Feb 28, 2013 at 1:43 PM, prateek mishra
wrote:
> SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization
> Grants
> JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
> Assertio
Hi Oleg,
my personal experience with Certicom's IPR disclosures is that they
focus on Elliptic Curve Cryptography. There were several IPR disclosures
on documents in the JOSE WG and some of them contain ECC algorithms.
The JWT does not list an ECC algorithm but the referenced documents do.
H
Two points -
1) I request that this mailing list NOT be used for any substantive
discussion of patent claims and so on. This will create difficulties for
many participants and
I dont believe is within the charter of this effort.
2) I would encourage interested parties to review the following
This is certainly a good point. Stating whether certain claims are valid
or not valid is not a good use of our time and may lead to legal
problems later on.
So, read through the patents and make your own assessment whether this
IPRs are a concern for you and whether you want anything in the dr
Hmmm, I'm not so sure. It depends where we all think OAuth is on its
trajectory. On one hand, OAuth has already seen an insanely massive amount of
deployment. On the other hand, RESTful APIs see no sign of slowing down. Now
I'm not going to go so far as Craig B. and say that everything and
On 02/28/2013 10:57 PM, Hannes Tschofenig wrote:
> This is certainly a good point. Stating whether certain claims are
> valid or not valid is not a good use of our time and may lead to legal
> problems later on.
>
> So, read through the patents and make your own assessment whether this
> IPRs are a
+1
From: Brian Campbell
Sent: 2/28/2013 1:00 PM
To: prateek mishra
Cc: oauth
Subject: Re: [OAUTH-WG] JWT - scope claim missing
Thanks Prateek. I like it and I think wordy might be the way to go here.
On Thu, Feb 28, 2013 at 1:43 PM, prateek mishra
mailto:pratee
Characteristics of both these attacks -
1) Use of implicit flow (access token passed on the URL)
2) changes to redirect uri (specification does allow some flexibility here)
3) applications with long-lived access tokens with broad scope (in one
case only)
- prateek
And a different one (still ex
Prateek,
It's not so much a "patent claim" discussion as a suggestion to do something
different than JWT if it's really protected by somebody's patents. It's a
public standard after all and it's in the interests of everyone to keep it this
way.
--- On Thu, 2/28/13, prateek mishra wrote:
Fr
I don't like that "implicit flow" or former user-agent much and wrote about it
2 years ago, but that attack is rather related to implementation bugs, not to
protocol itself. A root cause - a bug in redirect URL verification (probably a
regexp flaw).
Enforcing token's life time at a protocol le
With the caveat that I have not read the patent disclosures, I will add that if
they pertain to Elliptic Curve Cryptography, RFC 6090 is likely relevant -
especially http://tools.ietf.org/html/rfc6090#section-7.1 on ECDH and
http://tools.ietf.org/html/rfc6090#section-7.2 on ECDSA.
While implicit is what they are attacking, this is in principal also possible
to do with a code flow if the client is public.
It is only confidential clients using the code flow that have reasonable
protection from open redirectors.
In openID Connect we made registered redirect_uri and full comp
Mike and Hannes,
Thanks. Very useful info that needs to be explored further. I actually like the
W3C approach to the similar problem. It's described here:
http://www.w3.org/2011/xmlsec-pag/pagreport.html
1. They've created PAG.
2. Contacted the patent holder.
3. Reviewed patent holder's propo
58 matches
Mail list logo
