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 signatures of that stuff.
________________________________
From: Hannes Tschofenig <hannes.tschofe...@gmx.net>
To: IETF oauth WG <oauth@ietf.org>
Sent: Tuesday, February 12, 2013 1:10 AM
Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th
February 2013
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 then 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
