You have a trust relationship with the user and perhaps with the client.
________________________________
From: Prateek Mishra <prateek.mis...@oracle.com>
To: oauth@ietf.org
Sent: Wednesday, February 13, 2013 8:13 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
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.
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.
3) I think do need an MTI key distribution protocol as part of the
specification, leaving that as a choice would hurt interoperability.
- 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 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
