Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C4A28C123 for ; Tue, 15 Jun 2010 08:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7D2hkL06yUW for ; Tue, 15 Jun 2010 08:19:15 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 988FD3A6820 for ; Tue, 15 Jun 2010 08:19:14 -0700 (PDT) Received: by gwj16 with SMTP id 16so3431012gwj.31 for ; Tue, 15 Jun 2010 08:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jTnw42lPtq4fJkR05JWH2zN82M/Y5rbt2dibTPnXv5s=; b=RzAifFpgel9cGOiba+9oB6QxgNozlcZYJ/5qKwellR+Y6RPf/QJPjSoz7UMZIDoSXG pVEj/3FWmOLwFnT6ltATKEc8OYTxxvOOUcIlslIsZSfcaxbOsNvNc7TyMcoaxubu+LUM l0YLCGIAPwknLZVuTvd6dlN5/KrDPztwBROho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y5HZXahR+6Xb32TINSutDIkMA5pUtK62cDObrCRcwvswsOWxUzPDZyWzYa+PfEbUJb iVeD0+tNJtKsX22jYs5GSanrc4D5yyTckzD0ekkaea0IBqwZyXWPiGNmpMUvqHHRx/m1 kXqppGwzPvopatQM13ZTeZBc5NDaFyH9TjLwU= MIME-Version: 1.0 Received: by 10.150.246.23 with SMTP id t23mr8353470ybh.331.1276615156099; Tue, 15 Jun 2010 08:19:16 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Tue, 15 Jun 2010 08:19:16 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 15 Jun 2010 08:19:16 -0700 Message-ID: From: Andrew Arnott To: Dick Hardt Content-Type: multipart/alternative; boundary=000e0cd6c8dee4ea4804891320cd Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 15:19:16 -0000 --000e0cd6c8dee4ea4804891320cd Content-Type: text/plain; charset=ISO-8859-1 Hi Dick, Responses inline. On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt wrote: > Why can the client app access the AS to get an access token but not the > corporate network to get a new assertion? > The corporate network where the AD lives is behind a firewall, whereas the AS is on the public Internet. So when the client is on the public Internet, the AD is not available but the AS is. Also, the resource server is on the public Internet (probably obvious). How does the client app get the assertion to begin with? How did delegation > from the user happen? > There are two possible scenarios here, which I will outline and inject the steps in each scenario: 1. The client app is initially launched while on the corporate network 1. The client sends an HTTP request to *an *endpoint on a *corpnet *AS(1) (directly -- not through a browser), which sniffs the request for NTLM credentials (or however Windows auth does it) and if present immediately responds with an authorization code (a.k.a. verification code) rather than prompting the user for permission. This is considered reasonable in this application because the client is already running on a trusted machine and the privacy ramifications are minimal. 2. The client app exchanges the authorization code for a refresh token and an access token at the AS(2) token endpoint, which lies outside the corporate firewall, and can thereby refresh access tokens when the client is off corpnet. 3. All resource requests use an OAuth access token to gain access. 2. The client app is initially launched *off* the corporate network. 1. This just uses the standard user agent or web server flows, including prompting the user for authorization. > Would you elaborate more on the use case so that we can understand the full > trust model? > Perhaps my description above covers this question. I'll just add that the goal is to make the authorization process as painless (or altogether absent from the user's point of view) as possible. We're also considering providing customized app downloads to each user based on the Windows auth user that downloads the .zip file, such that the client app includes a file containing the authorization code encoded for that particular user. > The assertion flow was intended for autonomous clients rather than user > delegation -- hence Brian's response and mine that this is a different flow > if the access token is for user delegation. > That makes sense. > > Are you envisioning the client makes a call to AD to get an assertion where > the call is automagically authenticated as the user by NTLM? > Perhaps my scenarios above clarified this. My client never explicitly calls AD though. Whether that happens implicitly by the Windows platform, I don't know. What do you envision being the relationship between the AS and AD? What > authority does the AS have? How long is the refresh token valid for? > The refresh token would be valid until the user logged into the AS (or RS perhaps) to revoke it. The AD is altogether unaware of the AS, but the AS trusts the AD to have authenticated the user and trusts the AD assertion. --000e0cd6c8dee4ea4804891320cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dick,

Responses inline.

On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt <dick.hardt@gmail.com> w= rote:
Why can the client app access the AS to get an ac= cess token but not the=20 corporate network to get a new assertion?

= The corporate network where the AD lives is behind a firewall, whereas the = AS is on the public Internet.=A0 So when the client is on the public Intern= et, the AD is not available but the AS is.=A0 Also, the resource server is = on the public Internet (probably obvious).

How does=20 the client app get the assertion to begin with? How did delegation from=20 the user happen?

There are two p= ossible scenarios here, which I will outline and inject the steps in each s= cenario:
  1. The client app is initially launched while on the corpo= rate network
    1. The client sends an HTTP request to an endpoint on a corp= net AS(1) (directly -- not through a browser), which sniffs the request= for NTLM credentials (or however Windows auth does it) and if present imme= diately responds with an authorization code (a.k.a. verification code) rath= er than prompting the user for permission.=A0 This is considered reasonable= in this application because the client is already running on a trusted mac= hine and the privacy ramifications are minimal.
    2. The client app exchanges the authorization code for a refresh toke= n and an access token at the AS(2) token endpoint, which lies outside the c= orporate firewall, and can thereby refresh access tokens when the client is= off corpnet.
    3. All resource requests use an OAuth access token to gain access.
  2. The client app is initially launched off the corporat= e network.
    1. This just uses the standard user agent or web server= flows, including prompting the user for authorization.

Would yo= u elaborate more on=20 the use case so that we can understand the full trust model?

Perhaps my description above covers this question.= =A0 I'll just add that the goal is to make the authorization process as= painless (or altogether absent from the user's point of view) as possi= ble.=A0 We're also considering providing customized app downloads to ea= ch user based on the Windows auth user that downloads the .zip file, such t= hat the client app includes a file containing the authorization code encode= d for that particular user.


The assertion flow was intended for autonomous clients rather than user=20 delegation -- hence Brian's response and mine that this is a different= =20 flow if the access token is for user delegation.

That makes sense.
=A0
=A0
Are you envisioning th= e client makes a call to AD to get an assertion where the call is automagic= ally authenticated as the user by NTLM?=A0

Perhaps my scenarios above clarified this. My c= lient never explicitly calls AD though.=A0 Whether that happens implicitly = by the Windows platform, I don't know.

What do you envision = being the relationship between the AS and AD? What authority does the AS ha= ve? How long is the refresh token valid for?

The refresh token would be valid until the user logged into the AS (or = RS perhaps) to revoke it. The AD is altogether unaware of the AS, but the A= S trusts the AD to have authenticated the user and trusts the AD assertion.=
--000e0cd6c8dee4ea4804891320cd--