Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346DE21F8842 for ; Sun, 20 Jan 2013 23:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD5Fr32ybvAz for ; Sun, 20 Jan 2013 23:57:27 -0800 (PST) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by ietfa.amsl.com (Postfix) with ESMTP id A3D9421F8841 for ; Sun, 20 Jan 2013 23:57:26 -0800 (PST) Received: by mail-ea0-f170.google.com with SMTP id a11so2279391eaa.1 for ; Sun, 20 Jan 2013 23:57:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=1XRKZ/MPiuRkxM6YLbYgWK3b0zv/XVdoe5KZoz2/dCw=; b=Penq6GauWl+d2fx8IN7TfEuPT5W+lnZHIrFPuC0ofcK57v06qgUlehGWAqluxI7G/C R5hZUagHi2tcuJ3uYuFQ3YLPDq1w8HLqD7b97yqwCjWfLu3JtkKYW53chGaCVj+o3isM N69JAwxF5SGzIFpbZHwZmsBH03qSMnrsGA1iVMNwHCW/KD0cmeq2OySbKMWONNPn2VrJ nAj0i/Lf7+2fBVHH1M8/976V8R/GfHh/+pjXF8Ztv4VaszOLVVuKGlgVlJsL6ypAHxc6 D1WvfNg2GyuqeAPubPEHJAxzcu8hvrfC4V3OcNT8ihd7sfq+iOwN8tztOi5mgJNz/kgl P0aQ== MIME-Version: 1.0 X-Received: by 10.14.0.133 with SMTP id 5mr57417989eeb.29.1358755045406; Sun, 20 Jan 2013 23:57:25 -0800 (PST) Received: by 10.223.194.4 with HTTP; Sun, 20 Jan 2013 23:57:25 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Jan 2013 13:27:25 +0530 Message-ID: From: Prabath Siriwardena To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=047d7b66fef3d1780004d3c7cf77 X-Gm-Message-State: ALoCoQkt4wfpNbGqvjCnMcEh3cyKJQMZEQmPofKHBXUSFgvH+yh1K6Z6UR3RVGvMGJPCqJRjUMMs Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client cannot specify the token type it needs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 07:57:28 -0000 --047d7b66fef3d1780004d3c7cf77 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I am not objecting that RS should define it's requirements... and RS should be able to do it by each resource... So ideally RS may have away to express that in a WADL and we need to have a standard mechanism established for communication between RS and AS. In WS-Trust - SP can declare it's token requirements via WS-SecurityPolicy, in WSDL. And client reads the WSDL and identify the token requirements. Then based on those requirements, client talks to the STS and gets the token. Thanks & regards, -Prabath On Mon, Jan 21, 2013 at 1:07 PM, wrote: > > Prabath Siriwardena =D0=B4=D3=DA 2013-01-21 15:27:57: > > > > I guess that is a pattern used many scenarios. Requesting client can > > suggest - but its up to the AS to honor it or not... > > > Not exactly. For example, RS supports two token types, one is bear token, > another is holer-of-key which is assumed more secure than the first one. > RS realy wants the seconde type, but =A3=A8a dishonest=A3=A9 client, alwa= ys choosing > the weakest, requests the first one. > what is the meaning for client to specify the token type? > > > > > Thanks & regards, > > -prabath > > > On Mon, Jan 21, 2013 at 12:43 PM, wrote: > > > > William Mills =D0=B4=D3=DA 2013-01-21 13:44:45= : > > > > > > > Not a problem for the client to request a type, but it may not get it= . > > > > I don't object client requesting a type, but I think it is > > meaningful only when the requested type is specified by a RS, > > and client just relay that request to AS. > > > > > > > > From: "zhou.sujing@zte.com.cn" > > > To: Prabath Siriwardena > > > Cc: "oauth@ietf.org WG" ; William Mills > > > > > > Sent: Sunday, January 20, 2013 9:38 PM > > > Subject: Re: Re: Re: [OAUTH-WG] Client cannot specify the token > > type it needs > > > > > > > > > Well, if RS could specify token type, then Client could transfer it t= o > AS, > > > I think, but it is not a good idea for client itself to specify the > > > token type. > > > > > > > > > Prabath Siriwardena =D0=B4=D3=DA 2013-01-21 13:29:= 05: > > > > > > > Think about a distributed setup. You have single Authorization > > > > Server and multiple Resource Servers. > > > > > > > > Although OAuth nicely decouples AS from RS - AFAIK there is no > > > > standard established for communication betweens AS and RS - how to > > > > declare metadata between those. > > > > > > > > Also there can be Resource Servers which support multiple token > > > > types. It could vary on APIs hosted in a given RS. > > > > > > > > Thanks & regards, > > > > -Prabath > > > > > > > > On Mon, Jan 21, 2013 at 10:48 AM, wrote: > > > > > > > > The token type shoulbe decided by resource server, which consumes > > > > access token. > > > > Client just re-tell the requested token type to AS. > > > > Client should not specify the token type. > > > > > > > > > > > > oauth-bounces@ietf.org =D0=B4=D3=DA 2013-01-21 13:08:39: > > > > > > > > > > > > > This is true. It's possible for the AS to vary it's behavior on > > > > > scope name, but it's presumed the AS and RS have an agreement of > > > > > what token type is in play. Likely a good extension to the spec. > > > > > > > > > > > > > > From: Prabath Siriwardena > > > > > To: "oauth@ietf.org WG" > > > > > Sent: Sunday, January 20, 2013 7:28 PM > > > > > Subject: [OAUTH-WG] Client cannot specify the token type it needs > > > > > > > > > > > > > > Although token type is extensible according to the OAuth core > > > > > specification - it is fully governed by the Authorization Server. > > > > > > > > > > There can be a case where a single AS supports multiple token > types > > > > > based on client request. > > > > > > > > > > But currently we don't have a way the client can specify (or at > > > > > least suggest) which token type it needs in the OAuth access > > > tokenrequest ? > > > > > > > > > > Is this behavior intentional ? or am I missing something... > > > > > > > > > > Thanks & Regards, > > > > > Prabath > > > > > > > > > > Mobile : +94 71 809 6732 > > > > > > > > > > http://blog.facilelogin.com > > > > > http://RampartFAQ.com > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > > > -- > > > > Thanks & Regards, > > > > Prabath > > > > > > > > Mobile : +94 71 809 6732 > > > > > > > > http://blog.facilelogin.com > > > > http://RampartFAQ.com > > > > > > > > > > -- > > Thanks & Regards, > > Prabath > > > > Mobile : +94 71 809 6732 > > > > http://blog.facilelogin.com > > http://RampartFAQ.com > --=20 Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --047d7b66fef3d1780004d3c7cf77 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable I am not objecting that RS should define it's requirements...  and= RS should be able to do it by each resource... So ideally RS may have &nbs= p;away to express that in a WADL and we need to have a standard mechanism e= stablished for communication between RS and AS.

In WS-Trust - SP can declare it's token requirements via= WS-SecurityPolicy, in WSDL. And client reads the WSDL and identify the tok= en requirements. Then based on those requirements, client talks to the STS = and gets the token.

Thanks & regards,
-Prabath 

=
On Mon, Jan 21, 2013 at 1:07 PM, <zhou.su= jing@zte.com.cn> wrote:

Prabath Siriwardena <prabath@wso2.com> =D0=B4=D3=DA 2013-01-21 15:27:57:


> I guess that is a pattern used many scenarios. Requesting client can > suggest - but its up to the AS to honor it or not...

Not exactly. For example, RS supports two token types, one is bear token, another is holer-of-key which is assumed more secure than the first one.
RS realy wants the seconde type, but =A3=A8a dishonest=A3=A9 client, always choosing the weakest, requests the first one.
what is the meaning for client to specify the token type?

>
> Thanks & regards,
> -prabath
> On Mon, Jan 21, 2013 at 12:43 PM, <zhou.sujing@zte.com.cn> wrote:
>
> William Mills <wmills_92105@yahoo.com> =D0=B4=D3=DA 2013-01-21 13:44:45:
>
>
> > Not a problem for the client to request a type, but it may not get it.
>
> I don't object client requesting a type, but I think it is
> meaningful only when the requested type is specified by a RS,
> and client just relay that request to AS.
>
> >
> > From: "zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn>
> > To: Prabath Siriwardena <prabath@wso2.com>
> > Cc: "oau= th@ietf.org WG" <oauth@ietf.org>; William Mills
> > <w= mills_92105@yahoo.com>
> > Sent: Sunday, January 20, 2013 9:38 PM
> > Subject: Re: Re: Re: [OAUTH-WG] Client cannot specify the token
> type it needs
> >
> >
> > Well, if RS could specify token type, then Client could transfer it to AS,
> > I think, but it is not a good idea for client itself to specify the
> > token type.
> >
> >
> > Prabath Siriwardena <prabath@wso2.com> =D0=B4=D3=DA 2013-01-21 13:29:05:
> >
> > > Think about a distributed setup. You have single Authorizati= on
> > > Server and multiple Resource Servers.
> > >
> > > Although OAuth nicely decouples AS from RS - AFAIK there is no
> > > standard established for communication betweens AS and RS - how to
> > > declare metadata between those.
> > >
> > > Also there can be Resource Servers which support multiple token
> > > types. It could vary on APIs hosted in a given RS.
> > >
> > > Thanks & regards,
> > > -Prabath
> > >
> > > On Mon, Jan 21, 2013 at 10:48 AM, <zhou.sujing@zte.com.cn> wrote:
> > >
> > > The token type shoulbe decided by resource server, which consumes
> > > access token.
> > > Client just re-tell the requested token type to AS.
> > > Client should not specify the token type.
> > >
> > >
> > > = oauth-bounces@ietf.org =D0=B4=D3=DA 2013-01-21 13:08:39:
> > >
> > >
> > > > This is true.  It's possible for the AS to var= y it's behavior on
> > > > scope name, but it's presumed the AS and RS have an agreement of
> > > > what token type is in play.  Likely a good extensi= on to the spec.
> > >
> > > >
> > > > From: Prabath Siriwardena <prabath@wso2.com>
> > > > To: "oauth@ietf.org WG" <oauth@ietf.org>
> > > > Sent: Sunday, January 20, 2013 7:28 PM
> > > > Subject: [OAUTH-WG] Client cannot specify the token type it needs
> > >
> > > >
> > > > Although token type is extensible according to the OAuth core
> > > > specification - it is fully governed by the Authorizati= on Server.
> > > >
> > > > There can be a case where a single AS supports multiple token types
> > > > based on client request.
> > > >
> > > > But currently we don't have a way the client can sp= ecify (or at
> > > > least suggest) which token type it needs in the OAuth access
> > tokenrequest ?
> > > >
> > > > Is this behavior intentional ? or am I missing somethin= g...
> > > >
> > > > Thanks & Regards,
> > > > Prabath
> > > >
> > > > Mobile : +94 71 809 6732
> > > >
> > > > http://blog.facilelogin.com
> > > > htt= p://RampartFAQ.com
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAu= th@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAu= th@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> >
> > >
> > > --
> > > Thanks & Regards,
> > > Prabath
> > >
> > > Mobile : +94 71 809 6732
> > >
> > > ht= tp://blog.facilelogin.com
> > > http://R= ampartFAQ.com
> >
>

>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.= facilelogin.com
> http://RampartFAQ.= com



--
= Thanks & Regards,
Prabath

--047d7b66fef3d1780004d3c7cf77--