On 02/14/2013 02:45 AM, Hannes Tschofenig wrote:
Hi Prateek,
thanks for your questions.
On Feb 13, 2013, at 6:13 PM, Prateek Mishra wrote:
Hannes,
1) Its not clear to me that we need to specify exchanges between the AS and
the RS as part of this work. The core specification leaves this
unspecified. There could be many different ways that the AS and RS collaborate
to validate signatures in messages received from the client.
It depends what the group wants to accomplish. So far, I thought that the goal
was to offer the ability to provide a sufficient description in our
specifications so that the authorization server and the resource server can be
provided by different vendors and that they still interoperate.
The group may have changed their mind in the meanwhile.
What is your view?
My view on this, as expressed in the call, is that the interoperability
be between the Client and AS and between the Client and RS.
Interoperability between AS and RS from different vendors is a different
question all together, and I don't think it really ought to be in scope
for this. I think that with this signed token component we should build
something that doesn't *preclude* this kind of AS/RS interop, but that
the solution to that is a more general question. This is the motivation
behind things like the token introspection draft.
2) Regarding (symmetric) key distribution, dont we need some kind of existing
trust relationship between the client and AS to make this possible? I guess it
would be enough to require use of a "confidential" client, that would make it
possible for the two parties to agree on a session key at the point where an access token
is issued by the AS.
That's a very good question. I have not formed an option about this issue yet
particularly given the recent capability to dynamically register clients.
I don't think that signing tokens should require confidential clients.
This was one of the implementation issues with OAuth 1, as it required a
"consumer_secret" at all times. This led to Google telling people to use
"anonymous" as the "consumer_secret" for what were effectively public
clients. Even with dynamic registration, there's still a place for
public clients, in my opinion.
3) I think do need an MTI key distribution protocol as part of the
specification, leaving that as a choice would hurt interoperability.
That's my impression as well.
I agree that we need to pick one style that assumes which party needs
access to which keys and what time. I disagree that we need to define
exactly how all of those keys get there.
-- Justin
Ciao
Hannes
- prateek
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 discussions during the conference calls.
-- HTTP vs. JSON
Phil noted that he does not like to use the MAC Token draft as a starting point
because it does not re-use any of the work done in the JOSE working group and
in particular all the libraries that are available today. He mentioned that
earlier attempts to write the MAC Token code lead to problems for implementers.
Justin responded that he does not agree with using JSON as a transport
mechanism since this would replicate a SOAP style.
Phil noted that he wants to send JSON but the signature shall be computed over
the HTTP header field.
-- Flexibility for the keyed message digest computation
From earlier discussion it was clear that the conference call participants
wanted more flexibility regarding the keyed message digest computation. For
this purpose Hannes presented the DKIM based approach, which allows selective
header fields to be included in the digest. This is shown in slide #4.
After some discussion the conference call participants thought that this would
meet their needs. Further investigations would still be useful to determine the
degree of failed HMAC calculations due to HTTP proxies modifying the content.
-- Key Distribution
Hannes presented the open issue regarding the choice of key distribution.
Slides #6-#8 present three techniques and Hannes asked for feedback regarding
the preferred style. Justin and others didn't see the need to decide on one
mechanism - they wanted to keep the choice open. Derek indicated that this will
not be an acceptable approach. Since the resource server and the authorization
server may, in the OAuth 2.0 framework, be entities produced by different
vendors there is an interoperability need. Justin responded that he disagrees
and that the resource server needs to understand the access token and referred
to the recent draft submission for the token introspection endpoint. Derek
indicated that the resource server has to understand the content of the access
token and the token introspection endpoint just pushes the problem around: the
resource server has to send the access token to the authorization server and
then the resource server gets the result back (which he th
e
n a
gain needs to understand) in order to make a meaningful authorization
decision.
Everyone agreed that the client must receive the session key from the
authorization server and that this approach has to be standardized. It was also
agreed that this is a common approach among all three key distribution
mechanisms.
Hannes asked the participants to think about their preference.
The questions regarding key naming and the indication for the intended resource
server the client wants to talk to have been postponed.
Ciao
Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
