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 57DED3A67D6 for ; Tue, 15 Jun 2010 07:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, 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 cwCjR1LfuSPT for ; Tue, 15 Jun 2010 07:11:57 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 913C93A6801 for ; Tue, 15 Jun 2010 07:11:57 -0700 (PDT) Received: by pwi8 with SMTP id 8so3758180pwi.31 for ; Tue, 15 Jun 2010 07:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=qhv54YccMlGhSpt79gT51uCaAcW2NpQtMjjPMZ1/m2Q=; b=yBaWYLgEa9Fe7xkYFHcttwaNFGBiOcHttJYNj/UwNCa/08pHLGCPaTlqEb1jrKB/rX 5Vorjb/CoLWKYBwsxC8LZ9PjoL/TVdIzr1Xl88+wpdKjGQP6azRvsklNFNJWmLcFX7AR 4X/yfSVRZl2lnrZEAp4rzdX4zzJOkeQYuXobg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=mMi9Da0kkauP2BZKA/YN2o8qTu7yFRWCc93K8LSRTOesqHkdyLukNXeVyCADZ2D5h2 NoJ/NWSeYnVOqb6QfPXY/k6t0jNiIAAWHsCbJhCAG2DPgQPmTwUCkNwYrJb0QkN/OKmC 7mjk+1K6W7Yc91JwYS74ADkukdFn5bKCUapAo= Received: by 10.115.65.14 with SMTP id s14mr5754014wak.209.1276610756301; Tue, 15 Jun 2010 07:05:56 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id a23sm68700808wam.14.2010.06.15.07.05.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jun 2010 07:05:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-3--196673897 From: Dick Hardt In-Reply-To: Date: Tue, 15 Jun 2010 07:05:53 -0700 Message-Id: <035D0E28-4518-4C28-9744-E90EA4E22395@gmail.com> References: <7F00C2CF-E57F-4341-BBA4-7B03B69277D6@gmail.com> To: Andrew Arnott X-Mailer: Apple Mail (2.1078) 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 14:12:00 -0000 --Apple-Mail-3--196673897 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Why can the client app access the AS to get an access token but not the = corporate network to get a new assertion? How does the client app get the assertion to begin with? How did = delegation from the user happen? Would you elaborate more on the use case so that we can understand the = full trust model? 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. -- Dick On 2010-06-15, at 6:58 AM, Andrew Arnott wrote: > Well it's easy enough for me to just make up a profile that follows = rules I set. But since I don't think this need will be unique to = myself, would you like me to write up a spec somewhere? (I've never = written an IETF spec before) > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the = death your right to say it." - S. G. Tallentyre >=20 >=20 > On Mon, Jun 14, 2010 at 11:00 PM, Dick Hardt = wrote: > +1 >=20 > On 2010-06-14, at 9:02 PM, Brian Eaton wrote: >=20 > > On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott = wrote: > >> For an application I'm building, the installed client app will have > >> intermittent windows of time where it can obtain a (non-OAuth) = assertion for > >> user identity. During this time, it seems appropriate for it to = use the > >> assertion flow to obtain an OAuth authorization so that it can = impersonate > >> the user. So far this is just standard Assertion Flow stuff. But = without a > >> refresh_token, the app will break when the access token expires if = the app > >> doesn't have the ability at the moment (due to not being on the = corporate > >> network at the moment for example) to obtain a new assertion. = Since the > >> security model for this app would certainly allow for a = refresh_token to be > >> issued from the original OAuth authorization server exchange, this = would > >> solve it, if the spec didn't specifically ban such a parameter. > > > > I think this is a different use case than the one envisioned by most > > people who are using the assertion flow. > > > > I'm inclined to steer different use cases to different profiles. It > > makes it much easier to guide deployments, for example. > > > > Cheers, > > Brian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail-3--196673897 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Why = can the client app access the AS to get an access token but not the = corporate network to get a new assertion?

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

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

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.

-- = Dick

On 2010-06-15, at 6:58 AM, = Andrew Arnott wrote:

Well it's = easy enough for me to just make up a profile that follows rules I = set.  But since I don't think this need will be unique to myself, = would you like me to write up a spec somewhere? (I've never written an = IETF spec before)
--
Andrew Arnott
"I [may] not agree with what you have to say, but = I'll defend to the death your right to say it." - S. G. Tallentyre


On Mon, Jun 14, 2010 at 11:00 PM, = Dick Hardt <dick.hardt@gmail.com> = wrote:
+1

On 2010-06-14, at 9:02 PM, Brian Eaton wrote:

> On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott <andrewarnott@gmail.com> = wrote:
>> For an application I'm building, the installed client app will = have
>> intermittent windows of time where it can obtain a (non-OAuth) = assertion for
>> user identity.  During this time, it seems appropriate for = it to use the
>> assertion flow to obtain an OAuth authorization so that it can = impersonate
>> the user.  So far this is just standard Assertion Flow = stuff.  But without a
>> refresh_token, the app will break when the access token expires = if the app
>> doesn't have the ability at the moment (due to not being on the = corporate
>> network at the moment for example) to obtain a new assertion. =  Since the
>> security model for this app would certainly allow for a = refresh_token to be
>> issued from the original OAuth authorization server exchange, = this would
>> solve it, if the spec didn't specifically ban such a = parameter.
>
> I think this is a different use case than the one envisioned by = most
> people who are using the assertion flow.
>
> I'm inclined to steer different use cases to different profiles. =  It
> makes it much easier to guide deployments, for example.
>
> Cheers,
> Brian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



= --Apple-Mail-3--196673897--