Here are my notes.
Participants:
* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer
Notes:
My slides are available here:
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
Slide #2 summarizes earlier discussio
Hi all,
I just wanted to let you know that the draft agenda for the upcoming IETF
meeting is available here:
https://datatracker.ietf.org/meeting/86/agenda.txt
There are two OAuth sessions:
* MONDAY, March 11, 2013
1540-1710 Afternoon Session II
* THURSDAY, March 14, 2013
1740-1840 Afternoo
Is key distribution how AS and PR share keys for token encryption/decryption
or specifically about the keys for the HOK tokens?
For the MAC token spec, I don't actually care whether we use JSON or now, but
I'm in full agreement that we do NOT duplicate any HTTP info into the JSON.
Just signat
Hi Bill,
On Feb 12, 2013, at 11:27 AM, William Mills wrote:
> Is key distribution how AS and PR share keys for token encryption/decryption
> or specifically about the keys for the HOK tokens?
>
In order for the client to compute the keyed message digest it needs to have
the session key. This
For key exchange that's true for symmetric key, but no key exchange is required
for public key signing by the client.
There's so many possibilities here, but I think the best is that the key
materiel is conveyed in the token. The key could be included directly, or
another way to implement woul
Hi Hannes,
how this session key "differs" from the key described in the current draft [0]?
Thanks and regards
Antonio
[0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote:
> Hi Bill,
>
> On Feb 12, 2013, at 11:27 AM, William Mi
Hi Hannes, All,
On 12/02/13 09:10, Hannes Tschofenig wrote:
Here are my notes.
Participants:
* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer
Notes:
My slides are available here:
http://www.tschofenig.priv.at/OAuth2-S
The transport of the session key from the authorization server is described in
Section 5.1 and is called "mac_key".
The mechanism to transport the session key from the authorization server to the
resource server is not yet described in the document. This has historical
reasons: OAuth 1.0 did n
Hi Mike,
On 12/02/13 01:26, Mike Jones wrote:
At most, there should be two endpoints - creation and management - for a client, but the protocol
should be structured such that they *can* be at the same URL, if the server so chooses. A simple
way to accomplish this is to require that the client_
Thanks Hannes
On Feb 12, 2013, at 12:06 PM, Hannes Tschofenig wrote:
> The transport of the session key from the authorization server is described
> in Section 5.1 and is called "mac_key".
>
> The mechanism to transport the session key from the authorization server to
> the resource server is
OK, I can see the wisdom in changing this term.
I picked "valid" because I wanted a simple "boolean" value that would
require no additional parsing or string-matching on the client's behalf,
and I'd like to stick with that. OAuth is built with the assumption that
clients need to be able to rec
I'd be fine with the return from a creation request being a 201 instead
of a 200.
-- Justin
On 02/11/2013 06:33 PM, Richard Harrington wrote:
Since the request is an HTTP POST and a resource is created
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the
response should be an H
This is actually the approach that I favor now as well -- let the server
do the secret rotation if it wants to, and have the client be prepared
to receive a new client_secret or registration_access_token on any read
or update request.
This would necessitate changing the returned values, essent
?! /foo and /foo/bar are obviously distinct endpoints.
On Feb 12, 2013 3:25 AM, "Sergey Beryozkin" wrote:
> Hi Mike,
> On 12/02/13 01:26, Mike Jones wrote:
>
>> At most, there should be two endpoints - creation and management - for a
>> client, but the protocol should be structured such that they
The problem that I have with "always including the client_id" is *where*
to include it. Are we talking a query parameter, URI template, or
somewhere in the request body? The latter will only work for POST and
PUT, so it's out of the question to support GET and DELETE using that
semantic. I thin
Technically you could have your auth endpoint be:
/oauth?method=authorization
and your token endpoint be:
/oauth?method=token
and they're syntactically being served by the same URL. It's a
deep-in-the-weeds argument of little value whether or not you consider
these to be "separate endpoints"
It can be argued that /foo and /foo?provider=abc are different URI resources.
Nat and I were recommending that the registration return a update URI that can
be unique per client.
In the Apps for domains or Salesforce case the hosting client could be encoded
into the path or a parameter if req
On 12/02/13 14:43, Tim Bray wrote:
?! /foo and /foo/bar are obviously distinct endpoints.
definitely yes from the client's point of view, at the implementation
level - it is the internal detail, right ?
Cheers, Sergey
On Feb 12, 2013 3:25 AM, "Sergey Beryozkin" mailto:sberyoz...@gmail.co
So, I think we agree in general, but to be explicit: I want a server to
be free to include the client_id as an input parameter if it wants to,
but I would rather not have the client be required to compose that
parameter onto the base registration URL on its own. This is to preserve
the flexibil
I would be OK with the change to registration_access_url or something
similar to that. The main argument against it is that we'd be inventing
a bespoke field for something that's already covered out there by the
HTTP Linked Data world. Nat did a good job of trying to generalize
concepts of link
Returning a location header in the 201 ids fine as long as we also have the
same info as a claim.
I think most clients will want to process the JSON and store all the parameters
together. Making them fish out a header makes the W3C happy and is the correct
thing to do but taking it from a clai
One of the things I do not like about a MTI key transport mechanism if we put
it in the token is that there will be some systems that already have a per user
secret provisioned and we'll be forcing data duplication. If if the encrypted
token already includes any random component that could easi
Hi Justin,
I doubt whether valid_token would make a difference..?
My initial argument is what is the validation criteria..? Validation
criteria depends on the token_type..
If we are talking only about metadata - then I believe "revoked", "expired"
would be more meaningful..
Thanks & regards,
-P
Yes, that agrees with my thoughts on it.
John B.
On 2013-02-12, at 11:29 AM, Justin Richer wrote:
> This is actually the approach that I favor now as well -- let the server do
> the secret rotation if it wants to, and have the client be prepared to
> receive a new client_secret or registration
Agreed - I didn't think that header-only was the proposal, but let's be
explicit about the returned body always containing the URL. The way I
read the 201 definition, it suggests (SHOULD) that you use the location
header, but also says that the entity should refer to the new resource.
It was my
To some extent we want the server to have the flexibility it needs.
If the server knows it is going to need client_id for GET it needs to encode it
in the resource URI ether as part of the path or as a query parameter (that is
up to the server)
When doing updates the client MUST include the cli
On 02/12/2013 11:30 AM, John Bradley wrote:
To some extent we want the server to have the flexibility it needs.
If the server knows it is going to need client_id for GET it needs to encode it
in the resource URI ether as part of the path or as a query parameter (that is
up to the server)
Whe
The token may or may not need to be encrypted on top of being signed. All
tokens red to be signed.
If the Key is asymmetric or using DH key agreement it would not need to be
encrypted.
If it is a symmetric key then yes you need to use encrypted key transport.
The JOSE working group is worki
Actually, if it is to return it in the HTTP header, then it should
also use the RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that
it would be a hassle to obtain the header and store them in addition
to the JSON. So, it is nicer to have it in JSON bod
2013/2/13 Justin Richer :
>
> On 02/12/2013 11:30 AM, John Bradley wrote:
>>
>> To some extent we want the server to have the flexibility it needs.
>>
>> If the server knows it is going to need client_id for GET it needs to
>> encode it in the resource URI ether as part of the path or as a query
>>
This is the second rev of the metadata spec that we discussed at IETF
85 OAuth WG and subsequently the chairs asked for the draft.
Nat
-- Forwarded message --
From:
Date: 2013/2/13
Subject: New Version Notification for draft-sakimura-oauth-meta-02.txt
To: sakim...@gmail.com
Cc:
Clarification. I think Justin and I were in agreement that we don't want to
see a format that requires JSON payloads. We are both interested in a JSON
token used in the authorization header that could be based on a computed
signature of some combination of http headers and body if possible.
P
That's my reading of it as well, Phil, thanks for providing the
clarification. One motivator behind using a JSON-based token is to be
able to re-use some of the great work that the JOSE group is doing but
apply it to an HTTP payload.
What neither of us want is a token type that requires stuffi
+1
From: John Bradley
Sent: 2/12/2013 8:20 AM
To: Justin Richer
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Client secret rotation
Yes, that agrees with my thoughts on it.
John B.
On 2013-02-12, at 11:29 AM, Justin Richer wrote:
> This
Am 12.02.2013 um 15:57 schrieb Justin Richer :
>
> I think that's a very important difference.
I fully agree.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Then I think we've reached an acceptable resolution on this one. By having the
server return the registration_access_url upon create and having the client be
required to include the client_id upon update, servers are free to manage their
registration endpoint(s) as they see fit and clients alwa
I agree, and the "must include client_id" gels with the other discussion
of doing a full-replace for the PUT operation for updates from another
thread.
-- Justin
On 02/12/2013 01:37 PM, Mike Jones wrote:
Then I think we've reached an acceptable resolution on this one. By having the
server
On 2013-02-12, at 1:39 PM, Justin Richer wrote:
>
> On 02/12/2013 11:30 AM, John Bradley wrote:
>> To some extent we want the server to have the flexibility it needs.
>>
>> If the server knows it is going to need client_id for GET it needs to encode
>> it in the resource URI ether as part of
FYI, this issue is also being discussed as an OpenID Connect issue at
https://bitbucket.org/openid/connect/issue/747. I think that Nat's recent
comment there bears repeating on this list:
Nat Sakimura:
Not so sure. For example, PHP cannot get the JSON object form application/json
POST in
Part of the REST/JSON philosophy is that interfaces should be as simple and
developer-friendly as possible. XML was rejected by developers, in part,
because of the self-describing nature of the structure, which required extra
syntax that was often not useful in practice. Trying to re-impose th
Thanks for forwarding that, Mike. I'll paste in my response to Nat's
concern here as well:
It's an increasingly well known pattern that has reasonable support
on the server side. For PHP, I was able to find the above example
via the top hit on Stack Overflow. In Ruby, it's a matter of
Nat and I hashed out the pro's and cons of JSON requests.
If we POST or PUT a JSON object we need to be specific as there rare several
ways to do it that may work better or worse depending on the receiver.
This needs to be looked over and one picked.
In the other thread about the server return
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley wrote:
> Nat and I hashed out the pro's and cons of JSON requests.
>
> If we POST or PUT a JSON object we need to be specific as there rare
> several ways to do it that may work better or worse depending on the
> receiver.
> This needs to be looked o
The current privacy policy and TOS URL in registration are the ones for the
Client.
Nat and I discussed adding ones for the Authorization server that the client
agrees to as separate from ones that the user is agreeing to.
The Authorization servers TOS would be in discovery and perhaps in the
In this case, I believe that it really is a fairly straightforward case
of replacing the form-based key-value hash with a JSON-based key-value
hash. So all the existing parameters are converted into top-level JSON
objects, and the parameter values become the values of those members.
This is the
One question though: How exactly would the client, a software
application, agree to the TOS? Is it supposed to fetch the content of
the tos_url and do some processing on it? I wasn't under the impression
that the tos_url contents were machine readable. Is it supposed to
present that to the user
Some people apparently encode the JSON as the key in a form POST, some people
do a form POST with a special key and the JSON as the value.
There appear to be a number of theories in the wild. I am not an expert I
just looked up code examples from several sources stack overflow and the like.
If that's the question, then my proposal is the Content-type is
"application/json" and the HTTP Entity Body is the JSON document. No
form posts or parameter names to be had here.
-- Justin
On 02/12/2013 02:58 PM, John Bradley wrote:
Some people apparently encode the JSON as the key in a form
Just POST the JSON as the HTTP payload with mime-type application/json:
$ curl -v -H "Content-Type: application/json" -X POST -d '{"Hello": "World"}'
http://requestb.in/19qit4u1
* About to connect() to requestb.in port 80 (#0)
* Trying 107.20.236.186... connected
* Connected to requestb.in (107
There are two TOS and privacy policies.
One for the AS that the client is agreeing to by registering. Will it hold up
in court? don't know Facebook is doing this.
The link would be a reference to a human readable file that the client (RP) can
have someone look over before using the connection.
I agree with the previous statement that the AS's privacy/TOS would be
better handled through discovery, since it's not likely to change per
client instance.
-- Justin
On 02/12/2013 03:04 PM, John Bradley wrote:
There are two TOS and privacy policies.
One for the AS that the client is agree
I am fine with that as long as all the IdP tools have access to the entity body
in some reasonable way. That seems like the most sensible thing.
However given the number of people talking about encoding it in a form to get
access to it, we should check that it works for everyone.
John B.
On
+1 to what Pat and Justin said.
On Tue, Feb 12, 2013 at 12:59 PM, Justin Richer wrote:
> If that's the question, then my proposal is the Content-type is
> "application/json" and the HTTP Entity Body is the JSON document. No form
> posts or parameter names to be had here.
>
> -- Justin
>
>
>
I would then request that people come up with a real example of where it
*won't* work. I've seen workable solutions, and even some automagic
ones, on several major platforms in which one would write a web
server/AS: PHP, Java (Spring and raw servlets), Ruby (rails and
sinatra), and Node.js can
Let me explain a bit more.
A trust framework may supply several ToS and Privacy Policy options
much like CC licenses.
If we want to really automate the things, you really need it.
Otherwise, the service's owner need to go read the ToS and Privacy
Policy in person and makes the dynamic registration
I am OK with that language.
On 2013-02-12, at 5:16 PM, Justin Richer wrote:
> I would then request that people come up with a real example of where it
> *won't* work. I've seen workable solutions, and even some automagic ones, on
> several major platforms in which one would write a web server/
Like bunch of people expressed their opinion in the Thursday's OpenID
call, I honestly do not understand why you think this is complex.
It is JSON.
It is not a surprise.
Compare
obj = {
"registration_access_url":"http://example.com/";
};
obj = {
"_links":{"self":{"href":"http://example.com/"
If we are sending JSON, then the content-type should be application/json, or
some variant of it if needed be (e.g. application/oauthreg+json etc.
-- I do not think we need it, though.)
I do not like posting it with other content-type unless we explicitly
create a variable and
define a serializatio
I doubt that the ToS and Privacy Policy will be different for a given Trust
Framework provider, as these are all bilateral agreements, I do expect these to
be different between trust framework providers though
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org
59 matches
Mail list logo
