From hannes.tschofenig@gmx.net Wed Apr 4 09:01:23 2012 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 DA1B121F8472 for ; Wed, 4 Apr 2012 09:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4qHgVdc6k57 for ; Wed, 4 Apr 2012 09:01:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D61B321F845B for ; Wed, 4 Apr 2012 09:01:22 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2012 16:01:21 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp010) with SMTP; 04 Apr 2012 18:01:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18I4KodJA0IlBDmlqrILj3AtcdSWj6J56sQlTu0Lx Xg3bsfCNo+2zLe From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 4 Apr 2012 19:01:19 +0300 Message-Id: <47971AD6-A107-4F9F-8410-0E1636E325E6@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Meeting Minutes - IETF#83 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: Wed, 04 Apr 2012 16:01:24 -0000 Hey guys, Derek took notes during the meeting and I polished them a bit. Have a look at them and let us know if there is something missing: http://www.ietf.org/proceedings/83/minutes/minutes-83-oauth.txt Ciao Hannes & Derek From derek@ihtfp.com Wed Apr 4 09:21:57 2012 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 A98F121F86E0 for ; Wed, 4 Apr 2012 09:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i5Q-ZMtBW9w for ; Wed, 4 Apr 2012 09:21:57 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 4D69E21F8513 for ; Wed, 4 Apr 2012 09:21:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 34A192602A5; Wed, 4 Apr 2012 12:21:53 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 04921-02; Wed, 4 Apr 2012 12:21:51 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id C090B2602BF; Wed, 4 Apr 2012 12:21:50 -0400 (EDT) Received: from 192.168.248.158 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 4 Apr 2012 12:21:50 -0400 Message-ID: <469096e8be5a60b509cfa5cf35defc50.squirrel@mail2.ihtfp.org> In-Reply-To: <47971AD6-A107-4F9F-8410-0E1636E325E6@gmx.net> References: <47971AD6-A107-4F9F-8410-0E1636E325E6@gmx.net> Date: Wed, 4 Apr 2012 12:21:50 -0400 From: "Derek Atkins" To: "Hannes Tschofenig" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Meeting Minutes - IETF#83 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: Wed, 04 Apr 2012 16:21:57 -0000 Also, FYI, the audio recording of the meeting is available here: http://www.ietf.org/audio/ietf83/ietf83-252a-20120329-1256-pm.mp3 -derek On Wed, April 4, 2012 12:01 pm, Hannes Tschofenig wrote: > Hey guys, > > Derek took notes during the meeting and I polished them a bit. > > Have a look at them and let us know if there is something missing: > http://www.ietf.org/proceedings/83/minutes/minutes-83-oauth.txt > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From hannes.tschofenig@nsn.com Thu Apr 5 07:47:48 2012 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 F05BC21F86BE for ; Thu, 5 Apr 2012 07:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.9 X-Spam-Level: X-Spam-Status: No, score=-105.9 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEqEhXgho3vX for ; Thu, 5 Apr 2012 07:47:47 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7FA21F86C3 for ; Thu, 5 Apr 2012 07:47:46 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q35Elj5e030527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Apr 2012 16:47:45 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q35ElgsT000635 for ; Thu, 5 Apr 2012 16:47:45 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 16:46:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD133A.F33D3745" Date: Thu, 5 Apr 2012 17:46:57 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D014D5CD1@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on Assertion Drafts Thread-Index: Ac0TOvMdI0KJHLgrSYOXF98LEO+MPA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 05 Apr 2012 14:46:58.0160 (UTC) FILETIME=[F3B88700:01CD133A] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2944 X-purgate-ID: 151667::1333637265-00003570-E29D7214/0-0/0-0 Subject: [OAUTH-WG] WGLC on Assertion Drafts 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: Thu, 05 Apr 2012 14:47:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD133A.F33D3745 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 this is a Last Call for comments on these three documents: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10 http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02 Please have your comments in no later than April 23rd. Do remember to send a note in if you have read the document and have no other comments other than "it's ready to go" - we need those as much as we need "I found a problem". Thanks! Hannes & Derek ------_=_NextPart_001_01CD133A.F33D3745 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC on Assertion Drafts

Hi all, =

this is a Last Call for comments on these three = documents:

http= ://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10=

http:/= /tools.ietf.org/html/draft-ietf-oauth-assertions-01

=

http:/= /tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02

=

Please have = your comments in no later than April 23rd.

Do remember to = send a note in if you have read the document and have no other comments = other than "it’s ready to go" - we need those as much as we need = "I found a problem".

Thanks!

Hannes & = Derek

------_=_NextPart_001_01CD133A.F33D3745-- From jricher@mitre.org Thu Apr 5 09:53:48 2012 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 A5FCC21F871B for ; Thu, 5 Apr 2012 09:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un4skV1j4jPW for ; Thu, 5 Apr 2012 09:53:48 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB2D21F865D for ; Thu, 5 Apr 2012 09:53:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9A33E21B0A92 for ; Thu, 5 Apr 2012 12:53:46 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7442121B0A7D for ; Thu, 5 Apr 2012 12:53:46 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 5 Apr 2012 12:53:46 -0400 Message-ID: <4F7DCE03.3020009@mitre.org> Date: Thu, 5 Apr 2012 12:53:23 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: References: <999913AB42CC9341B05A99BBF358718D014D5CD1@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D014D5CD1@FIESEXC035.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------010908050505050206090205" X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] WGLC on Assertion Drafts 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: Thu, 05 Apr 2012 16:53:48 -0000 --------------010908050505050206090205 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit > http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 > Section 7's second portion about a client including multiple credentials types seems buried down here in the Error Responses section for something this fundamental. It also conflates discussion of selection of this client authorization type in here, where it ought to be in its own section, closer to the top. > http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02 > > This one seems fine to me, very straightforward. > http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10 > As I try to avoid SAML in general, I'm not a good person to comment on this draft. -- Justin --------------010908050505050206090205 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

http://tools.ietf.org/html/draft-ietf-oauth-assertions-01


Section 7's second portion about a client including multiple credentials types seems buried down here in the Error Responses section for something this fundamental. It also conflates discussion of selection of this client authorization type in here, where it ought to be in its own section, closer to the top.

http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02


This one seems fine to me, very straightforward.

http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10


As I try to avoid SAML in general, I'm not a good person to comment on this draft.

 -- Justin
--------------010908050505050206090205-- From kris.selden@gmail.com Thu Apr 5 12:38:45 2012 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 0996421F8647 for ; Thu, 5 Apr 2012 12:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qLD31RnD5mF for ; Thu, 5 Apr 2012 12:38:44 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F2F5221F8645 for ; Thu, 5 Apr 2012 12:38:43 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1783481pbb.31 for ; Thu, 05 Apr 2012 12:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=Oya+TGr4lAXrLRCX11tJjaQIn5+s+4LtuS9Hkl+6qMk=; b=S2SdXLlJCmgaxOQ/tNHg0Ld7BAywvI4NJGNWSghi89xRQuVuh+M3dFaqaJwnGHwrUH 0/L4OD5kGgIGBeZa+9LvRQFPafyhbndRyCJdX9fS/7CaKN1pcm7k46uSWy7kyFC9MEde GEBh7guwe3mgMe3uIFXNxWxB2UQ+r0gytm1+xY2VFdNZ+wpdG0tt9zqKhW7MneTwlBTZ ywCGQKfWyOluNLCYVPBCoz1tvcklVGXiHb7k06VVpJe6xFy5DC/CyZgnBM88xx1loiUT X4VMW7b9S9n1R+2/J2tC08UchAnG2rKonxXSRTvDcsZJyRAuhM9cGQWGr7VqXgIJSaZt Nh5g== Received: by 10.68.196.138 with SMTP id im10mr9095767pbc.156.1333654723517; Thu, 05 Apr 2012 12:38:43 -0700 (PDT) Received: from [192.168.169.6] (c-98-247-241-51.hsd1.wa.comcast.net. [98.247.241.51]) by mx.google.com with ESMTPS id r6sm4044159pbl.24.2012.04.05.12.38.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 12:38:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_67564068-15FF-4A10-93DF-3B8E3C3BB3B0" From: Kristofor Selden In-Reply-To: <038CA61F-9DB3-45BC-8DEF-85738F50EA97@matake.jp> Date: Thu, 5 Apr 2012 12:38:36 -0700 Message-Id: <5DBF7969-23BB-4131-BE1D-B2B27F7C030D@gmail.com> References: <62D85564-7961-4AB6-B1FA-B2DD75A4C74B@matake.jp> <90C41DD21FB7C64BB94121FBBC2E723453AFF08605@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453AFF08609@P3PW5EX1MB01.EX1.SECURESERVER.NET> <038CA61F-9DB3-45BC-8DEF-85738F50EA97@matake.jp> To: nov matake X-Mailer: Apple Mail (2.1257) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Clarification of "client application consisting of multiple components" 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: Thu, 05 Apr 2012 19:38:45 -0000 --Apple-Mail=_67564068-15FF-4A10-93DF-3B8E3C3BB3B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii How do I deal with this? https://twitter.com/#!/nov/status/187895781011890176 My assumption is after getting the user to authorize the client via the = FB SDK on the iPhone app, one would send the authorization code (not the = access token) back to the server via HTTPS where it would just get a new = token using the client id+secret and the authorization code, given that = the server client id is the same as iPhone apps client id. Is this correct? With mobile apps, having multiple components use the same client id is = going to be common regardless if that is less than ideal. It is common = to have a native mobile client component paired with a server component = both using FB social graph using the same client_id. For many startups FB won the social graph war and we just want to = leverage that and focus on our offerings. Thanks, Kris On Mar 11, 2012, at 10:43 AM, nov matake wrote: > I understood. > Thanks. >=20 > -- > nov >=20 > On Mar 12, 2012, at 2:30 AM, Eran Hammer wrote: >=20 >> That use case was removed from the specification. Either way, it is = up to the authorization server to decide which registration options to = offer the client if they make such a grant type available in the future, = and how it will apply the security policies. IOW, those proposing such = an extension in the future will have to figure out how this should be = handled. >>=20 >> EH >>=20 >>> -----Original Message----- >>> From: nov matake [mailto:nov@matake.jp] >>> Sent: Sunday, March 11, 2012 10:21 AM >>> To: Eran Hammer >>> Cc: nov matake; oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] Clarification of "client application = consisting of >>> multiple components" >>>=20 >>> So what is the usecase of response_type=3Dtoken%20code ? >>> I thought, in that usecase, token was for the client's client-side = component, >>> code was for the client's server-side component, and both of them = have the >>> same client_id. >>>=20 >>> -- >>> nov >>>=20 >>> On Mar 12, 2012, at 12:57 AM, Eran Hammer = wrote: >>>=20 >>>> If you have two components each with different security profile, = you must >>> assign each a different client_id. Otherwise, there is no way to = enforce the >>> rest of the spec's security requirements. >>>>=20 >>>> EH >>>>=20 >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>> Behalf Of nov matake >>>>> Sent: Sunday, March 11, 2012 8:25 AM >>>>> To: oauth@ietf.org WG >>>>> Subject: [OAUTH-WG] Clarification of "client application = consisting >>>>> of multiple components" >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I just found this sentence in the latest draft. >>>>>=20 >>>>> Does it mean "an application consisting of server-side and >>>>> client-side component (eg. foursquare iPhone app) MUST have = separate >>>>> client_id for each component" ? >>>>> Or can I image something like Facebook is doing right now? = (register >>>>> each component for a single client_id separately) >>>>>=20 >>>>> =3D=3D >>>>> A client application consisting of multiple components, each with = its >>>>> own client type (e.g. a distributed client with both a = confidential >>>>> server-based component and a public browser-based component), MUST >>>>> register each component separately as a different client to ensure >>>>> proper handling by the authorization server. The authorization >>>>> server MAY provider tools to manage such complex clients through a >>> single administration interface. >>>>> =3D=3D >>>>>=20 >>>>> -- >>>>> nov >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_67564068-15FF-4A10-93DF-3B8E3C3BB3B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://twit= ter.com/#!/nov/status/187895781011890176

My = assumption is after getting the user to authorize the client via the FB = SDK on the iPhone app, one would send the authorization code (not the = access token) back to the server via HTTPS where it would just get a new = token using the client id+secret and the authorization code, given that = the server client id is the same as iPhone apps client = id.

Is this = correct?

With mobile apps, having multiple = components use the same client id is going to be common regardless if = that is less than ideal.  It is common to have a native mobile = client component paired with a server component both using FB social = graph using the same client_id.

For many = startups FB won the social graph war and we just want to leverage that = and focus on our = offerings.

Thanks,
Kris

<= div>On Mar 11, 2012, at 10:43 AM, nov matake wrote:

I = understood.
Thanks.

--
nov

On Mar 12, 2012, at 2:30 = AM, Eran Hammer <eran@hueniverse.com> = wrote:

That use case was removed from = the specification. Either way, it is up to the authorization server to = decide which registration options to offer the client if they make such = a grant type available in the future, and how it will apply the security = policies. IOW, those proposing such an extension in the future will have = to figure out how this should be handled.

EH

-----Original = Message-----
From: nov matake = [mailto:nov@matake.jp]
Sent: Sunday, March 11, 2012 = 10:21 AM
To: Eran = Hammer
Cc: nov matake; oauth@ietf.org = WG
Subject: Re: [OAUTH-WG] Clarification of "client = application consisting of
multiple = components"

So what is the usecase of = response_type=3Dtoken%20code ?
I thought, in that usecase, = token was for the client's client-side = component,
code was for the client's = server-side component, and both of them have = the
same client_id.

--
nov

On Mar 12, 2012, at 12:57 AM, = Eran Hammer <eran@hueniverse.com> = wrote:

If you = have two components each with different security profile, you = must
assign each a different = client_id. Otherwise, there is no way to enforce = the
rest of the spec's security = requirements.

EH

-----Original = Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] = On
Behalf Of nov = matake
Sent: Sunday, March 11, 2012 = 8:25 = AM
To: oauth@ietf.org = WG
Subject: [OAUTH-WG] = Clarification of "client application = consisting
of multiple = components"

Hi,
<= blockquote type=3D"cite">

I just found this sentence in = the latest = draft.

Does it mean "an application = consisting of server-side = and
client-side component (eg. = foursquare iPhone app) MUST have = separate
client_id for each component" = ?
Or can I image something like = Facebook is doing right now? = (register
each component for a single = client_id = separately)

=3D=3D
A client application consisting = of multiple components, each with = its
own client type (e.g. a = distributed client with both a = confidential
server-based component and a = public browser-based component), = MUST
register each component = separately as a different client to = ensure
proper handling by the = authorization server.  The = authorization
server MAY provider tools to = manage such complex clients through = a
single administration = interface.
=3D=3D

--
nov <nov@matake.jp>
_______________________________________________
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
_______________________________= ________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


= --Apple-Mail=_67564068-15FF-4A10-93DF-3B8E3C3BB3B0-- From pranamcs@sg.ibm.com Thu Apr 5 13:09:34 2012 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 3C76821F866B for ; Thu, 5 Apr 2012 13:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+-Kb8pZFfWc for ; Thu, 5 Apr 2012 13:09:33 -0700 (PDT) Received: from e23smtp08.au.ibm.com (e23smtp08.au.ibm.com [202.81.31.141]) by ietfa.amsl.com (Postfix) with ESMTP id 066AD21F8663 for ; Thu, 5 Apr 2012 13:09:29 -0700 (PDT) Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 5 Apr 2012 20:06:47 +1000 Received: from d23relay03.au.ibm.com (202.81.31.245) by e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 5 Apr 2012 20:06:45 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q35K9GS81368130 for ; Fri, 6 Apr 2012 06:09:19 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q35K9GMh010564 for ; Fri, 6 Apr 2012 06:09:16 +1000 Received: from d23ml125.sg.ibm.com (d23ml125.sg.ibm.com [9.127.37.161]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q35K9GQx010550 for ; Fri, 6 Apr 2012 06:09:16 +1000 Auto-Submitted: auto-generated From: Codur Sreedhar Pranam To: oauth@ietf.org Message-ID: Date: Fri, 6 Apr 2012 04:03:23 +0800 X-MIMETrack: Serialize by Router on d23ml125/23/M/IBM(Release 8.5.1FP4|July 25, 2010) at 04/06/2012 04:03:24 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=C7BBF344DFFDAAEE8f9e8a93df938690918cC7BBF344DFFDAAEE" Content-Disposition: inline x-cbid: 12040510-5140-0000-0000-00000101E525 Subject: [OAUTH-WG] AUTO: Codur Sreedhar Pranam is out of the office (returning 04/25/2012) 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: Thu, 05 Apr 2012 20:09:34 -0000 --0__=C7BBF344DFFDAAEE8f9e8a93df938690918cC7BBF344DFFDAAEE Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 04/25/2012. Note: This is an automated response to your message "OAuth Digest, Vol= 42, Issue 2" sent on 4/6/12 3:00:08. This is the only notification you will receive while this person is awa= y.= --0__=C7BBF344DFFDAAEE8f9e8a93df938690918cC7BBF344DFFDAAEE Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 04/25/2012.




Note: This is an automated re= sponse to your message "OAuth Digest, = Vol 42, Issue 2" sen= t on 4/6/12 3:00:08.

This is the only notification= you will receive while this person is away.= --0__=C7BBF344DFFDAAEE8f9e8a93df938690918cC7BBF344DFFDAAEE-- From zachary.zeltsan@alcatel-lucent.com Thu Apr 5 13:33:59 2012 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 4B35F21F85C4 for ; Thu, 5 Apr 2012 13:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKZR6bjcUe5I for ; Thu, 5 Apr 2012 13:33:58 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E141721F85C0 for ; Thu, 5 Apr 2012 13:33:57 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q35KXs8o024705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Apr 2012 15:33:54 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q35KXsG6023112 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Apr 2012 15:33:54 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 5 Apr 2012 15:33:54 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Tschofenig, Hannes (NSN - FI/Espoo)'" , "'oauth@ietf.org'" Date: Thu, 5 Apr 2012 15:33:51 -0500 Thread-Topic: WGLC on Assertion Drafts Thread-Index: Ac0TOvMdI0KJHLgrSYOXF98LEO+MPAALZYCw Message-ID: <5710F82C0E73B04FA559560098BF95B1250DE5716F@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <999913AB42CC9341B05A99BBF358718D014D5CD1@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D014D5CD1@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B1250DE5716FUSNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [OAUTH-WG] WGLC on Assertion Drafts 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: Thu, 05 Apr 2012 20:33:59 -0000 --_000_5710F82C0E73B04FA559560098BF95B1250DE5716FUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The draft http://tools.ietf.org/html/draft-ietf-oauth-assertions-01, sectio= n 6.1 has the following requirement: The Authorization Server MUST validate the assertion in order to establish a mapping between the Issuer and the secret used to generat= e the assertion. I thought that checking a signature is a part of the assertion validation, = which cannot be done without knowing the mapping between the issuer and the= secret used to generate the assertion. It appears that the quoted text requires validation of the assertion prior = to checking the signature. What am I missing? Zachary From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= schofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, April 05, 2012 10:47 AM To: oauth@ietf.org Subject: [OAUTH-WG] WGLC on Assertion Drafts Hi all, this is a Last Call for comments on these three documents: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10 http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02 Please have your comments in no later than April 23rd. Do remember to send a note in if you have read the document and have no oth= er comments other than "it's ready to go" - we need those as much as we nee= d "I found a problem". Thanks! Hannes & Derek --_000_5710F82C0E73B04FA559560098BF95B1250DE5716FUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC on Assertion Drafts

Hell= o,

 <= /span>

The draft http://tools.ietf.org/html/draft-ietf-oauth-assertions-01,= section 6.1 has the following requirement:

The Authorization Server MUST validate the asserti= on in order to

 =      establish a mapping between the Issuer and the sec= ret used to generate the assertion.

 

I thought that checking a signature is a part of the assertion validation,= which cannot be done without knowing the mapping between the issuer and th= e secret used to generate the assertion.

It appears that the quoted text requires validation of = the assertion prior to checking the signature.

What am I missing?

 

<= span style=3D'font-size:11.0pt;font-family:"Trebuchet MS","sans-serif";colo= r:#1F497D'>Zachary

 

From: oauth-boun= ces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Tschofenig= , Hannes (NSN - FI/Espoo)
Sent: Thursday, April 05, 2012 10:47 AM=
To: oauth@ietf.org
Subject: [OAUTH-WG] WGLC on Asserti= on Drafts

 =

Hi all,

th= is is a Last Call for comments on these three documents:<= /p>

http://tools.ietf.org= /html/draft-ietf-oauth-saml2-bearer-10

http://tools.ietf.org/html/draft-ietf= -oauth-assertions-01

http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-= 02

Please have your comments in no later than April 23rd.

Do remember t= o send a note in if you have read the document and have no other comments o= ther than "it’s ready to go" - we need those as much as we = need "I found a problem".

Thanks!

Hannes & Derek<= /o:p>

= --_000_5710F82C0E73B04FA559560098BF95B1250DE5716FUSNAVSXCHMBSA_-- From nov@matake.jp Thu Apr 5 18:09:00 2012 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 8786921F8618 for ; Thu, 5 Apr 2012 18:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VP5Bw-Q8g4Nf for ; Thu, 5 Apr 2012 18:08:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F61021F8617 for ; Thu, 5 Apr 2012 18:08:58 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1231359ghb.31 for ; Thu, 05 Apr 2012 18:08:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=vmNvd3Cxu1pxEcNpKzCshz3ImYVJg4E3XlT11+c6KBE=; b=hoQd0Px/kQFttUMR0mLL0d8ZcJvfvBwjIS5+ujl+uGSTqB2BVKNCiTb6M4tmJeJise swUhsq2dbl/0muM96hpKl/w4shI0t43YsGP900Wu8t1SMou92GqAKDKb73tDE8Jryt25 1ARGalelOBKRpeLPfL7sUlDNNNa9tJqBOAZEhF6tBs+oaSyMYbJUNavgGOQmVCjg30yz r4ZJgnmNWYlXYnyMEQV4EqKm2IhZwpk9tmiHXiEHBwg2D4/rf5GHHgYZPHXuq/34qsgp kFc9RCQbZqBztU4P/6tfZH+UpoTSc9Np0AwtDQ2oKH/nmLsdBOooVFKfgXINbQzm2ozJ R8Mg== MIME-Version: 1.0 Received: by 10.236.197.66 with SMTP id s42mr4794025yhn.69.1333674538552; Thu, 05 Apr 2012 18:08:58 -0700 (PDT) Received: by 10.220.0.70 with HTTP; Thu, 5 Apr 2012 18:08:58 -0700 (PDT) X-Originating-IP: [124.32.97.98] In-Reply-To: <5DBF7969-23BB-4131-BE1D-B2B27F7C030D@gmail.com> References: <62D85564-7961-4AB6-B1FA-B2DD75A4C74B@matake.jp> <90C41DD21FB7C64BB94121FBBC2E723453AFF08605@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453AFF08609@P3PW5EX1MB01.EX1.SECURESERVER.NET> <038CA61F-9DB3-45BC-8DEF-85738F50EA97@matake.jp> <5DBF7969-23BB-4131-BE1D-B2B27F7C030D@gmail.com> Date: Fri, 6 Apr 2012 10:08:58 +0900 Message-ID: From: "matake, nov" To: Kristofor Selden Content-Type: multipart/alternative; boundary=20cf303f6d681dcf2504bcf84d27 X-Gm-Message-State: ALoCoQnMcW9JRJKEWlDqPSdmEGOiw9CBnqT6Hs3fE0pJZwjdFuvD1EMKKqUBRHYl/aUWxANYfc8o Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Clarification of "client application consisting of multiple components" 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: Fri, 06 Apr 2012 01:09:00 -0000 --20cf303f6d681dcf2504bcf84d27 Content-Type: text/plain; charset=ISO-8859-1 Let me describe the details first. FB iOS SDK delegates the authorization step to the official FB iOS app via "fbauth://authorize" custom schema URL. (If the official app isn't available on the device, it just open m.facebook.com authorization page using Safari) After the end-user approved the client access, FB server returns token and code to the official FB app. Then FB app passes token and code to the original app via the app's custom schema (fb123456://authorize, numeric part is FB app_id of the app). So if the app has its own server-side component, it should pass the code to the server, not the access token. (ref. http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html ) However, current FB iOS SDK just ignores the code and almost all developers seems not using code. Most apps are sending access tokens to their own server-side component. (foursquare, pinterest, yapp etc.) So the vulnerability John Bradley described before exists in many iOS app using FB iOS SDK now. (maybe Android apps too) http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html There are 2 solutions for this issue. First is modify FB iOS SDK and make code accessible from your app. I'm already talking with FB guys about it, so I hope they change their code by themselves. For now, you can use my fork of FB SDK too. https://github.com/nov/facebook-ios-sdk If 1st one is hard for you (because you cannot remove legacy version of your app from the users device etc), you can also use FB Graph API endpoint to verify access token audience. Send a GET request to graph.facebook.com/app?access_token=your-token, then you'll get application info to which the token is established. 2012/4/6 Kristofor Selden > How do I deal with this? > https://twitter.com/#!/nov/status/187895781011890176 > > My assumption is after getting the user to authorize the client via the FB > SDK on the iPhone app, one would send the authorization code (not the > access token) back to the server via HTTPS where it would just get a new > token using the client id+secret and the authorization code, given that the > server client id is the same as iPhone apps client id. > > Is this correct? > > With mobile apps, having multiple components use the same client id is > going to be common regardless if that is less than ideal. It is common to > have a native mobile client component paired with a server component both > using FB social graph using the same client_id. > > For many startups FB won the social graph war and we just want to leverage > that and focus on our offerings. > > Thanks, > Kris > > On Mar 11, 2012, at 10:43 AM, nov matake wrote: > > I understood. > Thanks. > > -- > nov > > On Mar 12, 2012, at 2:30 AM, Eran Hammer wrote: > > That use case was removed from the specification. Either way, it is up to > the authorization server to decide which registration options to offer the > client if they make such a grant type available in the future, and how it > will apply the security policies. IOW, those proposing such an extension in > the future will have to figure out how this should be handled. > > > EH > > > -----Original Message----- > > From: nov matake [mailto:nov@matake.jp] > > Sent: Sunday, March 11, 2012 10:21 AM > > To: Eran Hammer > > Cc: nov matake; oauth@ietf.org WG > > Subject: Re: [OAUTH-WG] Clarification of "client application consisting of > > multiple components" > > > So what is the usecase of response_type=token%20code ? > > I thought, in that usecase, token was for the client's client-side > component, > > code was for the client's server-side component, and both of them have the > > same client_id. > > > -- > > nov > > > On Mar 12, 2012, at 12:57 AM, Eran Hammer wrote: > > > If you have two components each with different security profile, you must > > assign each a different client_id. Otherwise, there is no way to enforce > the > > rest of the spec's security requirements. > > > EH > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > Behalf Of nov matake > > Sent: Sunday, March 11, 2012 8:25 AM > > To: oauth@ietf.org WG > > Subject: [OAUTH-WG] Clarification of "client application consisting > > of multiple components" > > > Hi, > > > I just found this sentence in the latest draft. > > > Does it mean "an application consisting of server-side and > > client-side component (eg. foursquare iPhone app) MUST have separate > > client_id for each component" ? > > Or can I image something like Facebook is doing right now? (register > > each component for a single client_id separately) > > > == > > A client application consisting of multiple components, each with its > > own client type (e.g. a distributed client with both a confidential > > server-based component and a public browser-based component), MUST > > register each component separately as a different client to ensure > > proper handling by the authorization server. The authorization > > server MAY provider tools to manage such complex clients through a > > single administration interface. > > == > > > -- > > nov > > _______________________________________________ > > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --20cf303f6d681dcf2504bcf84d27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Let me describe the details first.

FB iO= S SDK delegates the authorization step to the official FB iOS app via "= ;fbauth://authorize" custom schema URL.
(If the official app= isn't available on the device, it just open m.facebook.com authorization page using Safari)

After the end-user approved the client access, FB serve= r returns token and code to the official FB app.
Then FB app pass= es token and code to the original app via the app's custom schema (fb12= 3456://authorize, numeric part is FB app_id of the app).
So if the app has its own server-side component, it should pass the co= de to the server, not the access token.

However, current FB iOS SDK just ignores the code and a= lmost all developers seems not using code.
Most apps are sending = access tokens to their own server-side component. (foursquare, pinterest, y= app etc.)
So the vulnerability John Bradley described before exists in many iOS = app using FB iOS SDK now. (maybe Android apps too)

There are 2 solutions for this issue.

First is modify FB iOS SDK and make code accessible from your app.<= /div>
I'm already talking with FB guys about it, so I hope they cha= nge their code by themselves.
For now, you can use my fork of FB SDK too.

If 1st one is hard for you (because you canno= t remove legacy version of your app from the users device etc), you can als= o use FB Graph API endpoint to verify access token audience.
Send a GET request to graph.facebook.com/app?access_token=3Dyour-token, t= hen you'll get application info to which the token is established.

2012/4/6 Kristofor= Selden <kris.selden@gmail.com>
How= do I deal with this?

My assumption is after getting the user to authorize th= e client via the FB SDK on the iPhone app, one would send the authorization= code (not the access token) back to the server via HTTPS where it would ju= st get a new token using the client id+secret and the authorization code, g= iven that the server client id is the same as iPhone apps client id.

Is this correct?

With mobile a= pps, having multiple components use the same client id is going to be commo= n regardless if that is less than ideal. =A0It is common to have a native m= obile client component paired with a server component both using FB social = graph using the same client_id.

For many startups FB won the social graph war and we ju= st want to leverage that and focus on our offerings.

Thanks,
Kris

On Mar 11, 2012, at = 10:43 AM, nov matake wrote:

I understood.
Thanks.

--
no= v

On Mar 12, 2012, at 2:30 AM, Eran Hammer <eran@hueniverse.com> wrote:
<= br>
That use case was removed from the specification.= Either way, it is up to the authorization server to decide which registrat= ion options to offer the client if they make such a grant type available in= the future, and how it will apply the security policies. IOW, those propos= ing such an extension in the future will have to figure out how this should= be handled.

EH

-----Original Message-----
From: nov = matake [mailto:nov@matak= e.jp]
Sent: Sunday, March 11, 2012 10:21 AM
To: Eran Hammer
Cc: nov m= atake; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Clarification of "client application consis= ting of
multiple components"

So what is the usecase of response_t= ype=3Dtoken%20code ?
I thought, in that usecase, token was for the client's client-side c= omponent,
code was for the client's server-side component, and both of them have = the
same client_id.

--
nov
=

On Mar 12, 2012, at 12:57 AM, Eran Hammer = <eran@huenivers= e.com> wrote:

If you have two components each with di= fferent security profile, you must
assign each a different client_id. Otherwise, there is no w= ay to enforce the
rest of the spec's security requirements.
=

EH
<= br>
-----Original Message--= ---
From: oauth-bou= nces@ietf.org [mailto:oauth-bounces@ietf.org] On
Behalf Of nov matake
Sent: Sunday, March 11,= 2012 8:25 AM
To: oauth@ietf.org = WG
Subject: [OAUTH-WG] Clarification of "client application consisting
of multiple components"

Hi,
=

I just found this sentence in the lates= t draft.

Does it mean "an application consisting of server-side and
client-side component (= eg. foursquare iPhone app) MUST have separate
=
client_id for each component" ?
Or = can I image something like Facebook is doing right now? (register
each component for a single client_id separately)

=3D=3D
=
A clien= t application consisting of multiple components, each with its
own client type (e.g. a distributed client with both a confidential
server-= based component and a public browser-based component), MUST
register each compon= ent separately as a different client to ensure
proper handling by the authorizat= ion server. =A0The authorization
=
server MAY provider tools to manage such compl= ex clients through a
single administration interface.
=
=3D=3D

=
--
nov <nov@matake.jp>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________= ________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
=
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mail= ing list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth



--20cf303f6d681dcf2504bcf84d27-- From nov@matake.jp Thu Apr 5 18:19:03 2012 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 0B98921F8736 for ; Thu, 5 Apr 2012 18:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDM3ZNMDfcRl for ; Thu, 5 Apr 2012 18:19:01 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C70F21F86E8 for ; Thu, 5 Apr 2012 18:19:01 -0700 (PDT) Received: by yenm5 with SMTP id m5so1226572yen.31 for ; Thu, 05 Apr 2012 18:19:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=FDgnV+0vwIruxMHlk846VyIqDqeMzyiJ/Va5/azov2g=; b=l/8hGw+hNDR2o+OjsWSy5cn6zn0a9f7xmmhj3BKrtxqGf01DZqZFNCyrralC4+NeNU CGsScMV90+os9+OmOYK72Ncj96OiO2/b00DlyyjlbXsUtUT8UfHMm36LNnzlEgCt1I2M 9lG5ayMFcF/F1qKruAhgj0xp1BpdW90m5hhsgVD3/laHhgu6fzLEmzt0JezZY0cjzxhc QVRERqrY+8D7IhogvedWkPxfNOHVoSW1qpBwnMZBzLpBKU8nCypM9Uvle+5TKgx8sLDs jyjW8AA4kIPb2yfhifto/2sPr2foqr3TQPGRrKNchwlT/NfaMlt5EBFcxf4K0PjyTSk6 JykA== MIME-Version: 1.0 Received: by 10.101.138.33 with SMTP id q33mr1508995ann.76.1333675141130; Thu, 05 Apr 2012 18:19:01 -0700 (PDT) Received: by 10.220.0.70 with HTTP; Thu, 5 Apr 2012 18:19:01 -0700 (PDT) X-Originating-IP: [124.32.97.98] In-Reply-To: References: <62D85564-7961-4AB6-B1FA-B2DD75A4C74B@matake.jp> <90C41DD21FB7C64BB94121FBBC2E723453AFF08605@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723453AFF08609@P3PW5EX1MB01.EX1.SECURESERVER.NET> <038CA61F-9DB3-45BC-8DEF-85738F50EA97@matake.jp> <5DBF7969-23BB-4131-BE1D-B2B27F7C030D@gmail.com> Date: Fri, 6 Apr 2012 10:19:01 +0900 Message-ID: From: "matake, nov" To: Kristofor Selden Content-Type: multipart/alternative; boundary=0016e68ee348086a2804bcf871c7 X-Gm-Message-State: ALoCoQlQjMlR17SOMNyOrvXgw1XZen1AQoAqbgGGmC3Z8Fc865yre4wLCxjbdKpTp+P4Fy9ZXQBL Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Clarification of "client application consisting of multiple components" 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: Fri, 06 Apr 2012 01:19:03 -0000 --0016e68ee348086a2804bcf871c7 Content-Type: text/plain; charset=ISO-8859-1 OAuth Core spec doesn't define those cases, so OAuth WG ML isn't the place to report this issue though. * how to handle an app which consists both client-side and server-side components. * how to use OAuth for login I already reported this issue to * apple * facebook * foursquare * pinterest * yapp Not all of them are understanding this issue though.. 2012/4/6 matake, nov > Let me describe the details first. > > FB iOS SDK delegates the authorization step to the official FB iOS app via > "fbauth://authorize" custom schema URL. > (If the official app isn't available on the device, it just open > m.facebook.com authorization page using Safari) > > After the end-user approved the client access, FB server returns token and > code to the official FB app. > Then FB app passes token and code to the original app via the app's custom > schema (fb123456://authorize, numeric part is FB app_id of the app). > So if the app has its own server-side component, it should pass the code > to the server, not the access token. > (ref. > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html > ) > > However, current FB iOS SDK just ignores the code and almost all > developers seems not using code. > Most apps are sending access tokens to their own server-side component. > (foursquare, pinterest, yapp etc.) > So the vulnerability John Bradley described before exists in many iOS app > using FB iOS SDK now. (maybe Android apps too) > > http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html > > There are 2 solutions for this issue. > > First is modify FB iOS SDK and make code accessible from your app. > I'm already talking with FB guys about it, so I hope they change their > code by themselves. > For now, you can use my fork of FB SDK too. > https://github.com/nov/facebook-ios-sdk > > If 1st one is hard for you (because you cannot remove legacy version of > your app from the users device etc), you can also use FB Graph API endpoint > to verify access token audience. > Send a GET request to graph.facebook.com/app?access_token=your-token, > then you'll get application info to which the token is established. > > 2012/4/6 Kristofor Selden > >> How do I deal with this? >> https://twitter.com/#!/nov/status/187895781011890176 >> >> My assumption is after getting the user to authorize the client via the >> FB SDK on the iPhone app, one would send the authorization code (not the >> access token) back to the server via HTTPS where it would just get a new >> token using the client id+secret and the authorization code, given that the >> server client id is the same as iPhone apps client id. >> >> Is this correct? >> >> With mobile apps, having multiple components use the same client id is >> going to be common regardless if that is less than ideal. It is common to >> have a native mobile client component paired with a server component both >> using FB social graph using the same client_id. >> >> For many startups FB won the social graph war and we just want to >> leverage that and focus on our offerings. >> >> Thanks, >> Kris >> >> On Mar 11, 2012, at 10:43 AM, nov matake wrote: >> >> I understood. >> Thanks. >> >> -- >> nov >> >> On Mar 12, 2012, at 2:30 AM, Eran Hammer wrote: >> >> That use case was removed from the specification. Either way, it is up to >> the authorization server to decide which registration options to offer the >> client if they make such a grant type available in the future, and how it >> will apply the security policies. IOW, those proposing such an extension in >> the future will have to figure out how this should be handled. >> >> >> EH >> >> >> -----Original Message----- >> >> From: nov matake [mailto:nov@matake.jp] >> >> Sent: Sunday, March 11, 2012 10:21 AM >> >> To: Eran Hammer >> >> Cc: nov matake; oauth@ietf.org WG >> >> Subject: Re: [OAUTH-WG] Clarification of "client application consisting of >> >> multiple components" >> >> >> So what is the usecase of response_type=token%20code ? >> >> I thought, in that usecase, token was for the client's client-side >> component, >> >> code was for the client's server-side component, and both of them have the >> >> same client_id. >> >> >> -- >> >> nov >> >> >> On Mar 12, 2012, at 12:57 AM, Eran Hammer wrote: >> >> >> If you have two components each with different security profile, you must >> >> assign each a different client_id. Otherwise, there is no way to enforce >> the >> >> rest of the spec's security requirements. >> >> >> EH >> >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >> Behalf Of nov matake >> >> Sent: Sunday, March 11, 2012 8:25 AM >> >> To: oauth@ietf.org WG >> >> Subject: [OAUTH-WG] Clarification of "client application consisting >> >> of multiple components" >> >> >> Hi, >> >> >> I just found this sentence in the latest draft. >> >> >> Does it mean "an application consisting of server-side and >> >> client-side component (eg. foursquare iPhone app) MUST have separate >> >> client_id for each component" ? >> >> Or can I image something like Facebook is doing right now? (register >> >> each component for a single client_id separately) >> >> >> == >> >> A client application consisting of multiple components, each with its >> >> own client type (e.g. a distributed client with both a confidential >> >> server-based component and a public browser-based component), MUST >> >> register each component separately as a different client to ensure >> >> proper handling by the authorization server. The authorization >> >> server MAY provider tools to manage such complex clients through a >> >> single administration interface. >> >> == >> >> >> -- >> >> nov >> >> _______________________________________________ >> >> 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 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > --0016e68ee348086a2804bcf871c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OAuth Core spec doesn't define those cases, so OAuth WG ML isn't th= e place to report this issue though.
* how to handle an app which consi= sts both client-side and server-side components.
* how to use OAu= th for login

I already reported this issue to
* apple
* facebook
* foursquare
* pinterest
* y= app

Not all of them are understanding this issue t= hough..

2012/4/6 matake, nov = <nov@matake.jp>
Let me describe the details first.

FB iO= S SDK delegates the authorization step to the official FB iOS app via "= ;fbauth://authorize" custom schema URL.
(If the official app= isn't available on the device, it just open m.facebook.com authorization page using Safar= i)

After the end-user approved the client access, FB serve= r returns token and code to the official FB app.
Then FB app pass= es token and code to the original app via the app's custom schema (fb12= 3456://authorize, numeric part is FB app_id of the app).
So if the app has its own server-side component, it should pass the co= de to the server, not the access token.

However, current FB iOS SDK just ignores the code and a= lmost all developers seems not using code.
Most apps are sending = access tokens to their own server-side component. (foursquare, pinterest, y= app etc.)
So the vulnerability John Bradley described before exists in many iOS = app using FB iOS SDK now. (maybe Android apps too)

There are 2 solutions for this issue.

First is modify FB iOS SDK and make code accessible from your app.<= /div>
I'm already talking with FB guys about it, so I hope they cha= nge their code by themselves.
For now, you can use my fork of FB SDK too.

If 1st one is hard for you = (because you cannot remove legacy version of your app from the users device= etc), you can also use FB Graph API endpoint to verify access token audien= ce.
Send a GET request to graph.facebook.com/app?access_token= =3Dyour-token, then you'll get application info to which the token = is established.

2012/4/6 Kristofor= Selden <kris.selden@gmail.com>
How= do I deal with this?

My assumption is after getting the user to authorize th= e client via the FB SDK on the iPhone app, one would send the authorization= code (not the access token) back to the server via HTTPS where it would ju= st get a new token using the client id+secret and the authorization code, g= iven that the server client id is the same as iPhone apps client id.

Is this correct?

With mobile a= pps, having multiple components use the same client id is going to be commo= n regardless if that is less than ideal. =A0It is common to have a native m= obile client component paired with a server component both using FB social = graph using the same client_id.

For many startups FB won the social graph war and we ju= st want to leverage that and focus on our offerings.

Thanks,
Kris

On Mar 11, 2012, at = 10:43 AM, nov matake wrote:

I understood.
Thanks.

--
no= v

On Mar 12, 2012, at 2:30 AM, Eran Hammer <eran@hueniverse.com> wrote:
<= br>
That use case was removed from the specification.= Either way, it is up to the authorization server to decide which registrat= ion options to offer the client if they make such a grant type available in= the future, and how it will apply the security policies. IOW, those propos= ing such an extension in the future will have to figure out how this should= be handled.

EH

-----Original Message-----
From: nov = matake [mailto:nov@matak= e.jp]
Sent: Sunday, March 11, 2012 10:21 AM
To: Eran Hammer
Cc: nov m= atake; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Clarification of "client application consis= ting of
multiple components"

So what is the usecase of response_t= ype=3Dtoken%20code ?
I thought, in that usecase, token was for the client's client-side c= omponent,
code was for the client's server-side component, and both of them have = the
same client_id.

--
nov
=

On Mar 12, 2012, at 12:57 AM, Eran Hammer = <eran@huenivers= e.com> wrote:

If you have two components each with di= fferent security profile, you must
assign each a different client_id. Otherwise, there is no w= ay to enforce the
rest of the spec's security requirements.
=

EH
<= br>
-----Original Message--= ---
From: oauth-bou= nces@ietf.org [mailto:oauth-bounces@ietf.org] On
Behalf Of nov matake
Sent: Sunday, March 11,= 2012 8:25 AM
To: oauth@ietf.org = WG
Subject: [OAUTH-WG] Clarification of "client application consisting
of multiple components"

Hi,
=

I just found this sentence in the lates= t draft.

Does it mean "an application consisting of server-side and
client-side component (= eg. foursquare iPhone app) MUST have separate
=
client_id for each component" ?
Or = can I image something like Facebook is doing right now? (register
each component for a single client_id separately)

=3D=3D
=
A clien= t application consisting of multiple components, each with its
own client type (e.g. a distributed client with both a confidential
server-= based component and a public browser-based component), MUST
register each compon= ent separately as a different client to ensure
proper handling by the authorizat= ion server. =A0The authorization
=
server MAY provider tools to manage such compl= ex clients through a
single administration interface.
=
=3D=3D

=
--
nov <nov@matake.jp>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________= ________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
=
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mail= ing list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth




--0016e68ee348086a2804bcf871c7-- From Adam.Lewis@motorolasolutions.com Thu Apr 5 18:36:04 2012 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 28CAF11E8089 for ; Thu, 5 Apr 2012 18:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JINkpUfpPRxJ for ; Thu, 5 Apr 2012 18:36:03 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 10EC211E8080 for ; Thu, 5 Apr 2012 18:36:02 -0700 (PDT) Received: from mail141-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Apr 2012 01:36:01 +0000 Received: from mail141-va3 (localhost [127.0.0.1]) by mail141-va3-R.bigfish.com (Postfix) with ESMTP id 9EC53440608 for ; Fri, 6 Apr 2012 01:36:01 +0000 (UTC) X-SpamScore: 1 X-BigFish: VPS1(zzc85fhzz1202hzz8275bh8275dhz32i2a8h683h839hd25h) X-Forefront-Antispam-Report: CIP:192.160.210.20; KIP:(null); UIP:(null); IPV:NLI; H:il27msg01.am.mot-solutions.com; RD:il27msg01.mot-solutions.com; EFVD:NLI Received: from mail141-va3 (localhost.localdomain [127.0.0.1]) by mail141-va3 (MessageSwitch) id 1333676160127328_7399; Fri, 6 Apr 2012 01:36:00 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.245]) by mail141-va3.bigfish.com (Postfix) with ESMTP id 19B844C0043 for ; Fri, 6 Apr 2012 01:36:00 +0000 (UTC) Received: from il27msg01.am.mot-solutions.com (192.160.210.20) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Apr 2012 01:35:56 +0000 Received: from il27msg01.am.mot-solutions.com (ct11vts03.am.mot.com [10.177.16.162]) by il27msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q361l6Ln018698 for ; Thu, 5 Apr 2012 20:47:07 -0500 (CDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by il27msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q361l68T018695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Apr 2012 20:47:06 -0500 (CDT) Received: from mail163-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Apr 2012 01:35:53 +0000 Received: from mail163-tx2 (localhost [127.0.0.1]) by mail163-tx2-R.bigfish.com (Postfix) with ESMTP id 878924004CE for ; Fri, 6 Apr 2012 01:35:53 +0000 (UTC) Received: from mail163-tx2 (localhost.localdomain [127.0.0.1]) by mail163-tx2 (MessageSwitch) id 1333676151328162_17576; Fri, 6 Apr 2012 01:35:51 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.242]) by mail163-tx2.bigfish.com (Postfix) with ESMTP id 40FEA2006F for ; Fri, 6 Apr 2012 01:35:51 +0000 (UTC) Received: from CH1PRD0410HT001.namprd04.prod.outlook.com (157.56.244.181) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Apr 2012 01:35:50 +0000 Received: from CH1PRD0410MB369.namprd04.prod.outlook.com ([169.254.6.77]) by CH1PRD0410HT001.namprd04.prod.outlook.com ([10.255.147.36]) with mapi id 14.16.0135.002; Fri, 6 Apr 2012 01:35:49 +0000 From: Lewis Adam-CAL022 To: "oauth@ietf.org" Thread-Topic: draft-ietf-oauth-saml2-bearer-10 question Thread-Index: Ac0TlZgcTpLFLOatT/CbfOARUfhxCw== Date: Fri, 6 Apr 2012 01:35:49 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A906DCC7@CH1PRD0410MB369.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.21.49] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A906DCC7CH1PRD0410MB369na_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0410HT001.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False;00160000;True;; X-OrganizationHeadersPreserved: CH1PRD0410HT001.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Subject: [OAUTH-WG] draft-ietf-oauth-saml2-bearer-10 question 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: Fri, 06 Apr 2012 01:36:04 -0000 --_000_59E470B10C4630419ED717AC79FCF9A906DCC7CH1PRD0410MB369na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Reading draft-ietf-oauth-saml2-bearer-10, it states: The process by which the client obtains the SAML Assertion, prior to exchanging it with the authorization server or using it for client authentication, is out of scope. Accepting that it's out of scope from the draft, what are the realistic alt= ernatives to obtaining the SAML assertion out of band? WS-Trust provides a= direct method to request a SAML assertion from a STS, and the SAML ECP pro= files seems to allow this behavior, but it doesn't seem like ECP is very we= ll supported. What other viable means are there from a client to directly = request a SAML assertion from an assertion issuer? Tx! adam --_000_59E470B10C4630419ED717AC79FCF9A906DCC7CH1PRD0410MB369na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Reading draft-ietf-= oauth-saml2-bearer-10, it states:

 

The process= by which the client obtains the SAML Assertion, prior to=

  = ; exchanging it with the authorization server or using it for client

  = ; authentication, is out of scope.

 

Accepting that it&#= 8217;s out of scope from the draft, what are the realistic alternatives to = obtaining the SAML assertion out of band?  WS-Trust provides a direct = method to request a SAML assertion from a STS, and the SAML ECP profiles seems to allow this behavior, but it doesn’= ;t seem like ECP is very well supported.  What other viable means are = there from a client to directly request a SAML assertion from an assertion = issuer?

 

Tx!
adam

--_000_59E470B10C4630419ED717AC79FCF9A906DCC7CH1PRD0410MB369na_-- From ve7jtb@ve7jtb.com Thu Apr 5 18:47:56 2012 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 4E31321F85F1 for ; Thu, 5 Apr 2012 18:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1Mo8ui9Ud6w for ; Thu, 5 Apr 2012 18:47:55 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46BD621F85EF for ; Thu, 5 Apr 2012 18:47:54 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1233404yhk.31 for ; Thu, 05 Apr 2012 18:47:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=4RSLsbhXxkZNyaR0WOEsSaHaP9ZZp7N5canVzF3LKuQ=; b=f7l5+1WQ+FfLYmXeLkc7ZXboqoE7hIYUitvHetUO4RdUkMV9yq5Itjyui1rK+GCfBu VTbknCkOXfynHO9nuElp0F0SK9QRh1P02Xu5A/LyQJp7W46Q6ZzbSFMMoEFlbCUbvE5a Lt3tAGQ2XnnJI99Ywr9IKJMHfQFeJda8hhxlJ4TJeJFo+XiYZumqmq0CXkzWHyPJaqUH qCGwaVu+0aL2lFQjduOWU62+CG+iuG3JXQPhS1nUVc1d/J1zEdvwLpSf+IL3WCheHkH2 vK7agw7KGrFnCszmktkzsvlM23DSkPoBOjEQgLOhhB3IXE/kSvi43f5oP0IGedSObAwb tiqg== Received: by 10.236.181.8 with SMTP id k8mr4975902yhm.100.1333676874541; Thu, 05 Apr 2012 18:47:54 -0700 (PDT) Received: from [192.168.1.213] (190-20-28-75.baf.movistar.cl. [190.20.28.75]) by mx.google.com with ESMTPS id c4sm21700550yhm.18.2012.04.05.18.47.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 18:47:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_0CBF5AAD-636C-45B8-BCE3-A3D6C9E98C7A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <59E470B10C4630419ED717AC79FCF9A906DCC7@CH1PRD0410MB369.namprd04.prod.outlook.com> Date: Thu, 5 Apr 2012 22:46:45 -0300 Message-Id: <49B5B014-40B0-4ECC-B954-8BEF88564FEF@ve7jtb.com> References: <59E470B10C4630419ED717AC79FCF9A906DCC7@CH1PRD0410MB369.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmVhyeHCqcJ3PNpl+amod12BAkXlg7KiNdaitNI/AVMO1g8yYfjtq97RhXGRTVdryyZ6SaR Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-saml2-bearer-10 question 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: Fri, 06 Apr 2012 01:47:56 -0000 --Apple-Mail=_0CBF5AAD-636C-45B8-BCE3-A3D6C9E98C7A Content-Type: multipart/alternative; boundary="Apple-Mail=_58262B74-C8D2-47AE-A433-55EAA20473E0" --Apple-Mail=_58262B74-C8D2-47AE-A433-55EAA20473E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Adam, It may be a self signed SAML assertion. That is likely the case where someone wanted to use asymmetric keys to = authenticate to the Token Endpoint. I could see an STS used in some cases. ECP is a touch unlikely unless someone was super keen. The client could use a Web SSO profile to get a assertion for the user = if you are using the Assertion profile for the Authorization endpoint. There is also a JWT token profile for assertions, you knew I couldn't = resist a plug:) John B. On 2012-04-05, at 10:35 PM, Lewis Adam-CAL022 wrote: > Hi, > =20 > Reading draft-ietf-oauth-saml2-bearer-10, it states: > =20 > The process by which the client obtains the SAML Assertion, prior to > exchanging it with the authorization server or using it for client > authentication, is out of scope. > =20 > Accepting that it=92s out of scope from the draft, what are the = realistic alternatives to obtaining the SAML assertion out of band? = WS-Trust provides a direct method to request a SAML assertion from a = STS, and the SAML ECP profiles seems to allow this behavior, but it = doesn=92t seem like ECP is very well supported. What other viable means = are there from a client to directly request a SAML assertion from an = assertion issuer? > =20 > Tx! > adam > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_58262B74-C8D2-47AE-A433-55EAA20473E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Adam,

It may be a self = signed SAML assertion.

That is likely the case where = someone wanted to use asymmetric keys to authenticate to the Token = Endpoint.

I could see an STS used in some = cases.

ECP is a touch unlikely unless someone = was super keen.

The client could use a Web SSO = profile to get a assertion for the user if you are using the Assertion = profile for the Authorization endpoint.

There = is also a JWT token profile for assertions,  you knew I couldn't = resist a plug:)

John B.
On = 2012-04-05, at 10:35 PM, Lewis Adam-CAL022 wrote:

Hi,
 
Reading draft-ietf-oauth-saml2-bearer-10, it = states:
 
The process by which the client obtains the SAML Assertion, = prior to
   exchanging it with the authorization server or = using it for client
   authentication, is out of = scope.
 
Accepting that it=92s out of scope from the draft, what are the = realistic alternatives to obtaining the SAML assertion out of = band?  WS-Trust provides a direct method to request a SAML = assertion from a STS, and the SAML ECP profiles seems to allow this = behavior, but it doesn=92t seem like ECP is very well supported.  = What other viable means are there from a client to directly request a = SAML assertion from an assertion issuer?
OAuth@ietf.org
Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Clarification of "client application consisting of multiple components" 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: Fri, 06 Apr 2012 02:22:06 -0000 --Apple-Mail-EC144E3C-9736-4B62-9DDD-B5D7AF81F8E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, I understand that the spec leaves it ambiguous, I read the long thread on mu= ltiple components single client ID. I wanted to point out that this will be common despite this. Hopefully maybe= to encourage FB to start an extension clarify this. Thanks for your help, I had overlooked using graph.facebook.com/app?access_t= oken=3Dyour-token as a way to verify the client id. On Apr 5, 2012, at 6:19 PM, "matake, nov" wrote: > OAuth Core spec doesn't define those cases, so OAuth WG ML isn't the place= to report this issue though. > * how to handle an app which consists both client-side and server-side com= ponents. > * how to use OAuth for login >=20 > I already reported this issue to > * apple > * facebook > * foursquare > * pinterest > * yapp >=20 > Not all of them are understanding this issue though.. >=20 > 2012/4/6 matake, nov > Let me describe the details first. >=20 > FB iOS SDK delegates the authorization step to the official FB iOS app via= "fbauth://authorize" custom schema URL. > (If the official app isn't available on the device, it just open m.faceboo= k.com authorization page using Safari) >=20 > After the end-user approved the client access, FB server returns token and= code to the official FB app. > Then FB app passes token and code to the original app via the app's custom= schema (fb123456://authorize, numeric part is FB app_id of the app). > So if the app has its own server-side component, it should pass the code t= o the server, not the access token. > (ref. http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentica= tion.html) >=20 > However, current FB iOS SDK just ignores the code and almost all developer= s seems not using code. > Most apps are sending access tokens to their own server-side component. (f= oursquare, pinterest, yapp etc.) > So the vulnerability John Bradley described before exists in many iOS app u= sing FB iOS SDK now. (maybe Android apps too) > http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application= .html >=20 > There are 2 solutions for this issue. >=20 > First is modify FB iOS SDK and make code accessible from your app. > I'm already talking with FB guys about it, so I hope they change their cod= e by themselves. > For now, you can use my fork of FB SDK too. > https://github.com/nov/facebook-ios-sdk >=20 > If 1st one is hard for you (because you cannot remove legacy version of yo= ur app from the users device etc), you can also use FB Graph API endpoint to= verify access token audience. > Send a GET request to graph.facebook.com/app?access_token=3Dyour-token, th= en you'll get application info to which the token is established. >=20 > 2012/4/6 Kristofor Selden > How do I deal with this? > https://twitter.com/#!/nov/status/187895781011890176 >=20 > My assumption is after getting the user to authorize the client via the FB= SDK on the iPhone app, one would send the authorization code (not the acces= s token) back to the server via HTTPS where it would just get a new token us= ing the client id+secret and the authorization code, given that the server c= lient id is the same as iPhone apps client id. >=20 > Is this correct? >=20 > With mobile apps, having multiple components use the same client id is goi= ng to be common regardless if that is less than ideal. It is common to have= a native mobile client component paired with a server component both using = FB social graph using the same client_id. >=20 > For many startups FB won the social graph war and we just want to leverage= that and focus on our offerings. >=20 > Thanks, > Kris >=20 > On Mar 11, 2012, at 10:43 AM, nov matake wrote: >=20 >> I understood. >> Thanks. >>=20 >> -- >> nov >>=20 >> On Mar 12, 2012, at 2:30 AM, Eran Hammer wrote: >>=20 >>> That use case was removed from the specification. Either way, it is up t= o the authorization server to decide which registration options to offer the= client if they make such a grant type available in the future, and how it w= ill apply the security policies. IOW, those proposing such an extension in t= he future will have to figure out how this should be handled. >>>=20 >>> EH >>>=20 >>>> -----Original Message----- >>>> From: nov matake [mailto:nov@matake.jp] >>>> Sent: Sunday, March 11, 2012 10:21 AM >>>> To: Eran Hammer >>>> Cc: nov matake; oauth@ietf.org WG >>>> Subject: Re: [OAUTH-WG] Clarification of "client application consisting= of >>>> multiple components" >>>>=20 >>>> So what is the usecase of response_type=3Dtoken%20code ? >>>> I thought, in that usecase, token was for the client's client-side comp= onent, >>>> code was for the client's server-side component, and both of them have t= he >>>> same client_id. >>>>=20 >>>> -- >>>> nov >>>>=20 >>>> On Mar 12, 2012, at 12:57 AM, Eran Hammer wrote: >>>>=20 >>>>> If you have two components each with different security profile, you m= ust >>>> assign each a different client_id. Otherwise, there is no way to enforc= e the >>>> rest of the spec's security requirements. >>>>>=20 >>>>> EH >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>> Behalf Of nov matake >>>>>> Sent: Sunday, March 11, 2012 8:25 AM >>>>>> To: oauth@ietf.org WG >>>>>> Subject: [OAUTH-WG] Clarification of "client application consisting >>>>>> of multiple components" >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I just found this sentence in the latest draft. >>>>>>=20 >>>>>> Does it mean "an application consisting of server-side and >>>>>> client-side component (eg. foursquare iPhone app) MUST have separate >>>>>> client_id for each component" ? >>>>>> Or can I image something like Facebook is doing right now? (register >>>>>> each component for a single client_id separately) >>>>>>=20 >>>>>> =3D=3D >>>>>> A client application consisting of multiple components, each with its= >>>>>> own client type (e.g. a distributed client with both a confidential >>>>>> server-based component and a public browser-based component), MUST >>>>>> register each component separately as a different client to ensure >>>>>> proper handling by the authorization server. The authorization >>>>>> server MAY provider tools to manage such complex clients through a >>>> single administration interface. >>>>>> =3D=3D >>>>>>=20 >>>>>> -- >>>>>> nov >>>>>> _______________________________________________ >>>>>> 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 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 --Apple-Mail-EC144E3C-9736-4B62-9DDD-B5D7AF81F8E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks,

I understand that the spec leaves it ambiguous, I read the long threa= d on multiple components single client ID.

I wanted= to point out that this will be common despite this. Hopefully maybe to enco= urage FB to start an extension clarify this.


On Apr 5, 2012, at 6:19 PM, "matake,= nov" <nov@matake.jp> wrote:
<= br>
OAuth Core spec doesn't d= efine those cases, so OAuth WG ML isn't the place to report this issue thoug= h.
* how to handle an app which consists both client-side and server-sid= e components.
* how to use OAuth for login

I already reported this issue to
* apple
=
* facebook
* foursquare
* pinterest
* yap= p

Not all of them are understanding this issue thou= gh..

2012/4/6 matake, nov &= lt;nov@matake.jp>
Let me describe the details first.

FB iOS= SDK delegates the authorization step to the official FB iOS app via "fbauth://authorize" custom schema URL.
(If the official app isn't available on the device, it just open m.facebook.com authorization p= age using Safari)

After the end-user approved the client access, FB server= returns token and code to the official FB app.
Then FB app passes= token and code to the original app via the app's custom schema (fb123456://= authorize, numeric part is FB app_id of the app).
So if the app has its own server-side component, it should pass the cod= e to the server, not the access token.

However, current FB iOS SDK just ignores the code and al= most all developers seems not using code.
Most apps are sending ac= cess tokens to their own server-side component. (foursquare, pinterest, yapp= etc.)
So the vulnerability John Bradley described before exists in many iOS a= pp using FB iOS SDK now. (maybe Android apps too)

There are 2 solutions for this issue.

First is modify FB iOS SDK and make code accessible from your app.
I'm already talking with FB guys about it, so I hope they change the= ir code by themselves.
For now, you can use my fork of FB SDK too.

If 1st one is hard for you (be= cause you cannot remove legacy version of your app from the users device etc= ), you can also use FB Graph API endpoint to verify access token audience.
Send a GET request to graph.facebook.com/app?access_token=3Dy= our-token, then you'll get application info to which the token is establ= ished.

2012/4/6 Kristofor S= elden <kris.selden@gmail.com>
How d= o I deal with this?

My assumption is after getting the user to authorize the= client via the FB SDK on the iPhone app, one would send the authorization c= ode (not the access token) back to the server via HTTPS where it would just g= et a new token using the client id+secret and the authorization code, given t= hat the server client id is the same as iPhone apps client id.

Is this correct?

With mobile ap= ps, having multiple components use the same client id is going to be common r= egardless if that is less than ideal.  It is common to have a native mo= bile client component paired with a server component both using FB social gr= aph using the same client_id.

For many startups FB won the social graph war and we jus= t want to leverage that and focus on our offerings.

Thanks,
Kris

On Mar 11, 2012, at 10:= 43 AM, nov matake wrote:

I understood.
Thanks.

--
nov=

On Mar 12, 2012, at 2:30 AM, Eran Hammer <eran@hueniverse.com> wrote:

=
That use case was removed from the specification. E= ither way, it is up to the authorization server to decide which registration= options to offer the client if they make such a grant type available in the= future, and how it will apply the security policies. IOW, those proposing s= uch an extension in the future will have to figure out how this should be ha= ndled.

EH

-----Original Message-----
From: nov m= atake [mailto:nov@matake.= jp]
Sent: Sunday, March 11, 2012 10:21 AM
To: Eran Hammer
<= /blockquote>
Cc: nov mata= ke; oauth@ietf.org W= G
Subject: Re: [OAUTH-WG] Clarification of "client application consisting of=
multiple components"
=

So what is the usecase of response_type=3Dto= ken%20code ?
I thought, in that usecase, token was for the client's client-side compone= nt,
code was for the client's server-side component, and both of them have the
same client_id.

--
nov

On Mar 12, 2012, at 12:57 AM, Eran Hammer &l= t;eran@hueniverse.c= om> wrote:

If you have two components each with differ= ent security profile, you must
assign each a different client_id. Otherwise, there is no way= to enforce the
rest of the spec's security requirements.
EH
-----Original Message---= --
From: oauth-boun= ces@ietf.org [mailto:oauth-bounces@ietf.org] On
Behalf Of nov matake
Sent: Sunday, March 11, 2= 012 8:25 AM
To: oauth@ietf.org W= G
Subject: [OAUTH-WG] Clarification of "client application consisting
of multiple components"

Hi,
=

I just found this sentence in the latest dr= aft.

Does it mean "an application consisting of server-side and
client-side component (e= g. foursquare iPhone app) MUST have separate
=
client_id for each component" ?
Or can I im= age something like Facebook is doing right now? (register
each component for a single client_id separately)

=3D=3D
<= /blockquote>
A client ap= plication consisting of multiple components, each with its
own client type (e.g. a distributed client with both a confidential
<= /blockquote>
server-ba= sed component and a public browser-based component), MUST
register each componen= t separately as a different client to ensure
proper handling by the authorizatio= n server.  The authorization
=
server MAY provider tools to manage such complex= clients through a
single administration interface.
<= /blockquote>
=3D=3D
<= /blockquote>

--
nov <nov@matake.jp>
_______________________________________________
OAuth mailing list
=
OAuth@ietf.org
=
https://www.ietf.org/mailman/listinfo/oauth
<= /blockquote>
________________________= _______________________
OAuth ma= iling list
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<= /blockquote>_______________________________________________
OAuth mailing= list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

=


= --Apple-Mail-EC144E3C-9736-4B62-9DDD-B5D7AF81F8E8-- From bcampbell@pingidentity.com Fri Apr 6 04:55:45 2012 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 816E821F8531 for ; Fri, 6 Apr 2012 04:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpNF6VBHeuIh for ; Fri, 6 Apr 2012 04:55:44 -0700 (PDT) Received: from psmtp.com (na3sys009aog136.obsmtp.com [74.125.149.85]) by ietfa.amsl.com (Postfix) with ESMTP id 127AB21F8541 for ; Fri, 6 Apr 2012 04:55:43 -0700 (PDT) Received: from mail-vb0-f54.google.com ([209.85.212.54]) (using TLSv1) by na3sys009aob136.postini.com ([74.125.148.12]) with SMTP ID DSNKT37Zv4drIsES1J9/ChKofIXQ1oMTLq46@postini.com; Fri, 06 Apr 2012 04:55:44 PDT Received: by vbmv11 with SMTP id v11so1645157vbm.13 for ; Fri, 06 Apr 2012 04:55:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=2QGvj0Qxhmrwq1Um+mvHJTjmq5EH7FcmMnnMcq5L/aA=; b=FiPAv7Lm4sV4FymhGj2rQ7CAmdeOx2/YkIC5tK/I7xEfM3V//pX+wiHlYF3aSejLgL hqiC+R7QyPWGesvaU/oymP8b7sV2mf/Ul8Y6bLfzP1l48x8zdPbWiBaBzGG7D5hvf8N0 3TEAq1iujg05E4VwPk4Cuo3eBfbj7I0zhofmi0N2j+hNsQLjgqQI5m1zmBh0kXRPIm87 T9VSAyh3gznFwGv5v2/1kd6zexWtgEgn2ZIhgpg+F09vISXU5wWtSyNPsxRxysjCmKdB A03+ybLva+r43MXzFIj3EHwNKLJBuaWNVwsqjy2uwJqyJh9471uv5UXsUzSXAJgHPNmp py4g== Received: by 10.52.34.79 with SMTP id x15mr2110937vdi.0.1333713342495; Fri, 06 Apr 2012 04:55:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.36.47 with HTTP; Fri, 6 Apr 2012 04:55:12 -0700 (PDT) In-Reply-To: <49B5B014-40B0-4ECC-B954-8BEF88564FEF@ve7jtb.com> References: <59E470B10C4630419ED717AC79FCF9A906DCC7@CH1PRD0410MB369.namprd04.prod.outlook.com> <49B5B014-40B0-4ECC-B954-8BEF88564FEF@ve7jtb.com> From: Brian Campbell Date: Fri, 6 Apr 2012 05:55:12 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=20cf3079b82602fc6a04bd015642 X-Gm-Message-State: ALoCoQkLIfFiHWkquJRQLY8W5txgmlKuA7VkWtEHsMWAJFpI0OrZSPmAf3yOzhuiw5NoYi5NKsYP Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-saml2-bearer-10 question 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: Fri, 06 Apr 2012 11:55:45 -0000 --20cf3079b82602fc6a04bd015642 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It really depends on the situation - what other systems are available to the client and the nature of the trust relationship between the client and the AS. As John said, a client could generate and self sign an assertion. This likely works for well for client authentication via asymmetric keys. WS-Trust/STS is the most typical (in my view anyway) way a client might get an assertion to use for authorization. We've got a few customers doing it that way. I did a little demo a while back using WS-Trust but where the assertion issuer acts as a broker of sorts in the transaction rather than returning the assertion to the client: https://www.pingidentity.com/blogs/pingtalk/index.cfm/2010/11/5/Securing-Mo= bile-for-Enterprise--SAML-OAuth-WSTrust-in-Action ECP is possible but you are right that lack of support for it makes it unlikely. Various permutations of Web SSO are possible too. The client might be a SAML SP, for example, and get an assertion from an IDP that's suitable for both SSO and use as a grant type. Although, in current practice, I don't think IDP support for issuing such assertions is very good. And there's nothing ruling out some kind of simple proprietary exchange between the client and the assertion issuer. On Thu, Apr 5, 2012 at 7:46 PM, John Bradley wrote: > Adam, > > It may be a self signed SAML assertion. > > That is likely the case where someone wanted to use asymmetric keys to > authenticate to the Token Endpoint. > > I could see an STS used in some cases. > > ECP is a touch unlikely unless someone was super keen. > > The client could use a Web SSO profile to get a assertion for the user if > you are using the Assertion profile for the Authorization endpoint. > > There is also a JWT token profile for assertions, you knew I couldn't > resist a plug:) > > John B. > On 2012-04-05, at 10:35 PM, Lewis Adam-CAL022 wrote: > > Hi,**** > ** ** > Reading draft-ietf-oauth-saml2-bearer-10, it states:**** > ** ** > The process by which the client obtains the SAML Assertion, prior to**** > exchanging it with the authorization server or using it for client**** > authentication, is out of scope.**** > ** ** > Accepting that it=92s out of scope from the draft, what are the realistic > alternatives to obtaining the SAML assertion out of band? WS-Trust > provides a direct method to request a SAML assertion from a STS, and the > SAML ECP profiles seems to allow this behavior, but it doesn=92t seem lik= e > ECP is very well supported. What other viable means are there from a > client to directly request a SAML assertion from an assertion issuer?**** > ** ** > Tx! > adam**** > _______________________________________________ > 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 > > --20cf3079b82602fc6a04bd015642 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It really depends on the situation - what other systems are available to th= e client and the nature of the trust relationship between the client and th= e AS.=A0

As John said, a client could generate and self sign an ass= ertion. This likely works for well for client authentication via asymmetric= keys.

WS-Trust/STS is the most typical (in my view anyway) way a client might= get an assertion to use for authorization. We've got a few customers d= oing it that way.=A0 I did a little demo a while back using WS-Trust but wh= ere the assertion issuer acts as a broker of sorts in the transaction rathe= r than returning the assertion to the client: https://www.pingidentity.com/blogs/pingtal= k/index.cfm/2010/11/5/Securing-Mobile-for-Enterprise--SAML-OAuth-WSTrust-in= -Action

ECP is possible but you are right that lack of support for it makes it = unlikely.

Various permutations of Web SSO are possible too.=A0 The c= lient might be a SAML SP, for example, and get an assertion from an IDP tha= t's suitable for both SSO and use as a grant type. Although, in current= practice, I don't think IDP support for issuing such assertions is ver= y good.

And there's nothing ruling out some kind of simple proprietary exch= ange between the client and the assertion issuer.


On Thu, Apr 5, 2012 at 7:46 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
Ada= m,

It may be a self signed SAML assertion.

That is likely the case where someone wanted to use asymmetric keys to= authenticate to the Token Endpoint.

I could see a= n STS used in some cases.

ECP is a touch unlikely = unless someone was super keen.

The client could use a Web SSO profile to get a asserti= on for the user if you are using the Assertion profile for the Authorizatio= n endpoint.

There is also a JWT token profile for = assertions, =A0you knew I couldn't resist a plug:)

John B.
On 2= 012-04-05, at 10:35 PM, Lewis Adam-CAL022 wrote:

Hi,
=A0
R= eading draft-ietf-oauth-saml2-bearer-10, it states:
=A0
The proces= s by which the client obtains the SAML Assertion, prior to
=A0=A0 exc= hanging it with the authorization server or using it for client
=A0=A0 aut= hentication, is out of scope.
=A0
A= ccepting that it=92s out of scope from the draft, what are the realistic al= ternatives to obtaining the SAML assertion out of band?=A0 WS-Trust provide= s a direct method to request a SAML assertion from a STS, and the SAML ECP = profiles seems to allow this behavior, but it doesn=92t seem like ECP is ve= ry well supported.=A0 What other viable means are there from a client to di= rectly request a SAML assertion from an assertion issuer?
=A0
Tx!
adam
=
_______________________________________________
OAuth mailin= g list
OAuth@ietf.org
https://www.ietf.org/mailman/= listinfo/oauth


_= ______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--20cf3079b82602fc6a04bd015642-- From alexey.melnikov@isode.com Tue Apr 10 06:47:46 2012 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 6AFED21F85F4; Tue, 10 Apr 2012 06:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrIGDDjWgWMK; Tue, 10 Apr 2012 06:47:45 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC6021F85D6; Tue, 10 Apr 2012 06:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334065664; d=isode.com; s=selector; i=@isode.com; bh=XNGmDZTKRipUA6dftlaMuOIziTczDoq3IBCKRkSlcdE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Wd8UspvHARyeVhqASVJhssS1uMUrz2xuTVqBmT30chhQeBQmMsmFiC8O9ggnBsSh/zAGmx BDWCKp7st6OgtPU3pA4uHSOVomY7BHIctfB+ttPw78Flm+IrntNh0bLW7VgKWqROqGEnKv GaBT0eadY24c4fIOPPZMeEgjpSlwI9c=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Apr 2012 14:47:43 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F843A22.4020908@isode.com> Date: Tue, 10 Apr 2012 14:48:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Mike Jones References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F27C37C.1090008@isode.com> In-Reply-To: <4F27C37C.1090008@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: General Area Review Team , "oauth@ietf.org" , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] [Gen-art] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt 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: Tue, 10 Apr 2012 13:47:46 -0000 Hi Mike, On 31/01/2012 10:33, Alexey Melnikov wrote: > On 30/01/2012 05:20, Mike Jones wrote: >> Thanks for your useful feedback, Alexey. > Hi Mike, >> Below, I'll respond to each of your comments. I've also added the >> OAuth working group to the thread, so they are aware of them as well >> and can participate in the discussion. [...] >> About your comments on scope: OAuth 2.0 (both the Core and Bearer >> specs) is designed to be deployed in diverse and non-interoperable >> application contexts, meeting a variety of application needs. In >> those various settings, which are often distinct and potentially >> non-interoperable, parameters such as scope, realm, etc. may have >> very different meanings. This is not a bug; it is a feature, because >> it allows the OAuth pattern to meet the needs of numerous, often >> distinct, application environments. For that reason, a registry of >> scope (or realm) parameters would be ill-advised and >> counterproductive. It's perfectly OK and expected for a scope value >> such as "email" to have one meaning in one application context and a >> different meaning in a different, but distinct application context. >> Trying to impose a single meaning on particular scope values across >> distinct application contexts is both unnecessary and could break >> many existing deployments. That being said, we fully expect >> interoperability profiles to emerge that define interoperable sets of >> scope values within particular application contexts. (The OpenID >> Connect specifications are one such set of profiles.) But these >> meanings will always be context-specific - not global in scope. > The way "scope" is currently defined in the document is completely > useless. You don't have a single example in the document. You don't > say how the semantics of the value differs from realm. You don't say > that its values are deployment specific and can be profiled in future > documents. Please say something about these issues in the document > (your explanation above would work.) [...] >> About your second minor issue on error codes, the error codes >> registry already exists, but is in the OAuth Core spec. See >> http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-11.4. > Can you please make this clear in the document (by adding a reference)? I didn't see any of these addressed in -16...18. If I've missed that or if I've missed the discussion why these are not valid concerns, please let me know. From stephen.farrell@cs.tcd.ie Tue Apr 10 06:57:17 2012 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 2E20F11E80BE for ; Tue, 10 Apr 2012 06:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da2Yt5bXJ+pE for ; Tue, 10 Apr 2012 06:57:16 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC1F21F865B for ; Tue, 10 Apr 2012 06:57:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5FB2F171479 for ; Tue, 10 Apr 2012 14:57:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334066234; bh=8KU4/N7iBLjvlb n/MUC+WLpbXy7wa2DDWGwENRaJFRY=; b=ks3689l/4F/rbnr58gKLGEXs+mJNNm qGPfjrNRmv2Ch1E6CisdQWLh6XoSj7uiN7Zi0SDHOp3Dnk+LOlVZW0FPXIDRjFCr 8e8ACEtircLPK3CWwpngSh83OQeuF8vfdcwI1nKfXYp/s3jI6eapDu+7avOOooe3 /PJF1DWWcvQ9vcBpeICrxLEL6st6GwQGFkKvscfVwGvylCIvUEwPwO/oQYX3fTYR eM6TZu3o6LwaSlMLVWZt/Mi0ar64UBggmK2DY0ifC+xZCK4DhyQaGI8SHVbU25Sz XSQLxY6kztsydu5aa4FzR4JtUId1RBE5DCO4TKETllefiydP07/bKeHg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 9uYrA45PknVL for ; Tue, 10 Apr 2012 14:57:14 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DD6B2171472 for ; Tue, 10 Apr 2012 14:57:14 +0100 (IST) Message-ID: <4F843C3B.3040009@cs.tcd.ie> Date: Tue, 10 Apr 2012 14:57:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "oauth@ietf.org" References: <22E22875-8112-42A3-974D-770167AB9536@bbn.com> In-Reply-To: <22E22875-8112-42A3-974D-770167AB9536@bbn.com> X-Forwarded-Message-Id: <22E22875-8112-42A3-974D-770167AB9536@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Fwd: Gen-ART Telechat review of draft-ietf-oauth-v2-25 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: Tue, 10 Apr 2012 13:57:17 -0000 FYI in case some aren't on ietf@ietf.org Having responses to these before Thursday would be good. Its often the case that some AD will turn some of these points into a DISCUSS so good to know what can be cleared up easily and what might need further discussion before the telechat. S -------- Original Message -------- Subject: Gen-ART Telechat review of draft-ietf-oauth-v2-25 Date: Tue, 10 Apr 2012 09:11:19 -0400 From: Richard L. Barnes To: General Area Review Team , draft-ietf-oauth-v2.all@tools.ietf.org, IETF-Discussion list I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Document: draft-ietf-oauth-v2.txt Reviewer: Richard Barnes Review Date: 10 Apr 2012 IETF LC End Date: IESG Telechat Date: 12 Apr 2012 Summary: Almost ready, but with some gaps that need to be addressed MAJOR: General: At several points, the document seems to deal in plain-text usernames and passwords, ranging from the requirement for HTTP Basic authentication (2.3.1) to the explicit username and password fields one of the grant types (4.3.2, 10.7). In these cases, it seems like it would encourage better security practices to use some sort of digest or other secure scheme for proving ownership of passwords. Otherwise, there's a risk that proxies, caches, etc. will have access to users' plaintext credentials. General: The document requires the Authorization Server to distinguish between confidential and public clients at several points. It's not clear, however, how the server is supposed to tell which is which. Perhaps Section 2.1 could elaborate a little more on this? 4: Throughout the document, the assumption is that the client is moved from one URI to another via HTTP redirects (302 responses). Could the protocol also accommodate other techniques of moving clients around, e.g., in JavaScript (setting window.location). It seems like this could make deployment much easier in some cases. 10.3: This section seems to ignore the risk of client impersonation at the resource server. Just as with client credentials in Section 10.2, if an access token is compromised, then it could be presented by another party in order to access the protected resource. So the Resource Server needs to authenticate the client and validate that the token goes with the client, in addition to just checking the validity of the token. 10: Throughout this section, there are mentions of which parameters require secure transmission/storage and which do not. It would be helpful to summarize these requirements, say in a table at the end of the section. MINOR: 2.3.1: When you say "request body" in this section, do you actually mean "query"? I don't see a prohibition on GET here, in which case the parameters would be in the URI query section. 3.1.2.2: It seems like an explicit requirement would be helpful here, e.g.: " The Authorization Server MUST verify that either no redirect_uri is provided (in which case it uses the registered URI), or else that the provided redirect_uri matches the registered redirection URI for the authenticated client_id (where the match can be based on a full or partial registered URI). " 4.1.3: Why does this request use redirect_uri and not client_id to identify the client? (Or both?) It seems like involving the client_id would better support the goal of client authentication, in order to mitigate the risk of client impersonation. 4.3.2: Shouldn't there be a client authentication here? (In particular, a client_id.) Otherwise, it seems like this is essentially the same as the flow in 4.4. 7. It seems like it would be helpful to have a way to pass access tokens in the request URI / query in some deployment cases (e.g., a JavaScript based client). Is there any particular reason this was excluded? EDITORIAL: 3. Would be helpful to note here that these endpoints are in addition to the resource endpoint (the one started out to protect), which is handled in Section 7. 3.2: It's not clear why only POST is allowed here. A couple of words of explanation would help. 5.1: Why bother with a case-insensitive token_type here? It doesn't look like anything else in the whole document has this property. From alexey.melnikov@isode.com Tue Apr 10 07:02:37 2012 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 5439211E80D5; Tue, 10 Apr 2012 07:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9EswgLPvxrz; Tue, 10 Apr 2012 07:02:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 52E8211E80D3; Tue, 10 Apr 2012 07:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334066555; d=isode.com; s=selector; i=@isode.com; bh=bYQCBLIapiUTmkuq8okRogKIFoQ5k3TMEx2zcTMW47E=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cUKknYQcFaZrKmvjSkIP/Z1yOODUoHiUWhjaFTJl6b7p1UMtT5K7Ib4zxjjTzZ+xQmoeuM yWiQjxhzOP3QpfB0yuzEcoWRtTPZUV2kAzQndzsco4hjn6DFDET7W/fIgVp81/gEz/Rztp c0YBGOkJG2mx/5b4XWcU+LcWaVt9GXk=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Apr 2012 15:02:35 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F843DA1.8080703@isode.com> Date: Tue, 10 Apr 2012 15:03:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F27C37C.1090008@isode.com> <4F843A22.4020908@isode.com> In-Reply-To: <4F843A22.4020908@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: General Area Review Team , "oauth@ietf.org" , The IESG Subject: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt 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: Tue, 10 Apr 2012 14:02:37 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-oauth-v2-bearer-18.txt Reviewer: Alexey Melnikov Review Date: 10 April 2012 IETF LC End Date: 7 Feb 2012 IESG Telechat date: 12 April 2012 Summary: Nearly ready to be published as Proposed Standard, with a couple of things that should be addressed or at least discussed. Thank you for addressing most of my other issues. However there are a couple remaining which I think are important. Major Issues: 1). The "scope" attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. In some cases, the "scope" value will be used when requesting a new access token with sufficient scope of access to utilize the protected resource. The "scope" attribute MUST NOT appear more than once. The "scope" value is intended for programmatic use and is not meant to be displayed to end users. I don't think this provide enough information about what this is, how it is to be used and which values are allowed. As this is not meant to be displayed to end users, then you need to say what values are allowed and which entity can allocate them. Is there a registry for these tokens, e.g. an IANA registry? The editor provided explanation in email, however this was not reflected in any version of the draft. 2). Section "3.1. Error Codes" I've suggested to use an IANA registry for this field. Apparently there is already a registry created by . However this document doesn't register values defined in section 3.1 with IANA and doesn't point to draft-ietf-oauth-v2-23 for the registry. I find this to be very confusing. Minor issues: none Nits: none From jricher@mitre.org Tue Apr 10 07:11:48 2012 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 6A34D11E80CF for ; Tue, 10 Apr 2012 07:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gluiLEuYg9Tu for ; Tue, 10 Apr 2012 07:11:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C734511E80CD for ; Tue, 10 Apr 2012 07:11:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3BD3321B1988 for ; Tue, 10 Apr 2012 10:11:41 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1B59821B02C8 for ; Tue, 10 Apr 2012 10:11:41 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 10 Apr 2012 10:11:40 -0400 Message-ID: <4F843F76.8000503@mitre.org> Date: Tue, 10 Apr 2012 10:11:02 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F27C37C.1090008@isode.com> <4F843A22.4020908@isode.com> <4F843DA1.8080703@isode.com> In-Reply-To: <4F843DA1.8080703@isode.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt 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: Tue, 10 Apr 2012 14:11:48 -0000 > The "scope" attribute is a space-delimited list of scope values > indicating the required scope of the access token for accessing the > requested resource. In some cases, the "scope" value will be used > when requesting a new access token with sufficient scope of access to > utilize the protected resource. The "scope" attribute MUST NOT > appear more than once. The "scope" value is intended for > programmatic use and is not meant to be displayed to end users. > > I don't think this provide enough information about what this is, how > it is to be used and which values are allowed. As this is not meant to > be displayed to end users, then you need to say what values are > allowed and which entity can allocate them. Is there a registry for > these tokens, e.g. an IANA registry? > > The editor provided explanation in email, however this was not > reflected in any version of the draft. Scopes are service specific and as such their values and semantics are defined by each individual authorization server and are not coordinated through any centralized repository, registry, or standards body. So long as it fits the syntax defined by the grammar, any string is allowed. > > 2). Section "3.1. Error Codes" > > I've suggested to use an IANA registry for this field. Apparently > there is already a registry created by > . > However this document doesn't register values defined in section 3.1 > with IANA and doesn't point to draft-ietf-oauth-v2-23 for the > registry. I find this to be very confusing. Seems like there should be a simple pointer to OAuth2 section 8.5 or 11.4 here, and "insufficient_scope" does need to be registered, doesn't it? Though these are errors coming from the PR and not the token endpoint, so maybe they all need to be registered. -- Justin From Michael.Jones@microsoft.com Tue Apr 10 17:25:07 2012 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 3F4D811E812C; Tue, 10 Apr 2012 17:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YI2aBARC2Y2; Tue, 10 Apr 2012 17:25:06 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 705F211E80FD; Tue, 10 Apr 2012 17:25:06 -0700 (PDT) Received: from mail193-ch1-R.bigfish.com (10.43.68.226) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Apr 2012 00:25:05 +0000 Received: from mail193-ch1 (localhost [127.0.0.1]) by mail193-ch1-R.bigfish.com (Postfix) with ESMTP id 7766E2602ED; Wed, 11 Apr 2012 00:25:05 +0000 (UTC) X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail193-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail193-ch1 (localhost.localdomain [127.0.0.1]) by mail193-ch1 (MessageSwitch) id 1334103903768780_14168; Wed, 11 Apr 2012 00:25:03 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail193-ch1.bigfish.com (Postfix) with ESMTP id B6DDD1C0055; Wed, 11 Apr 2012 00:25:03 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Apr 2012 00:25:03 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0283.004; Wed, 11 Apr 2012 00:25:02 +0000 From: Mike Jones To: Alexey Melnikov , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" Thread-Topic: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt Thread-Index: Ac0XeYjHJBC3cdHfRaCIvdSewfDQIQ== Date: Wed, 11 Apr 2012 00:25:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436646237B@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: General Area Review Team , Russ Housley , "oauth@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt 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: Wed, 11 Apr 2012 00:25:07 -0000 Hi Alexey, About your issue 1: The OAuth Core spec, where "scope" is primarily define= d, includes the sentence "The [scope] strings are defined by the authorizat= ion server" (see http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-= 3.3). I could add that clarification to the Bearer spec as well to make it= clear that the scope values are context-dependent, if that would address y= our concern. About your issue 2: Investigating the OAuth Errors Registry a bit further = (see http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-11.4.1) whil= e I'd like to be able to register the OAuth Bearer errors in this registry,= what I believe to be a defect in the errors registry text currently preven= ts this. Specifically, the registry enumerates only three "Error usage loc= ation" values: authorization code grant error response, implicit grant err= or response, and token error response. To be able to use this registry, it= would also have to have a fourth usage location: "resource access error r= esponse". If you'd like to file an issue against the OAuth Core spec to ge= t this additional usage location added to the registry, then I'd be glad to= use it. I believe that this would be significantly preferable to adding a= separate OAuth Bearer errors registry that's exactly like the general-purp= ose one, only separate from it. Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= lexey Melnikov Sent: Tuesday, April 10, 2012 7:03 AM To: draft-ietf-oauth-v2-bearer.all@tools.ietf.org Cc: General Area Review Team; oauth@ietf.org; The IESG Subject: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-1= 8.txt I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-oauth-v2-bearer-18.txt Reviewer: Alexey Melnikov Review Date: 10 April 2012 IETF LC End Date: 7 Feb 2012 IESG Telechat date: 12 April 2012 Summary: Nearly ready to be published as Proposed Standard, with a couple o= f things that should be addressed or at least discussed. Thank you for addressing most of my other issues. However there are a coupl= e remaining which I think are important. Major Issues: 1). The "scope" attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. In some cases, the "scope" value will be used when requesting a new access token with sufficient scope of access to utilize the protected resource. The "scope" attribute MUST NOT appear more than once. The "scope" value is intended for programmatic use and is not meant to be displayed to end users. I don't think this provide enough information about what this is, how it is= to be used and which values are allowed. As this is not meant to be displa= yed to end users, then you need to say what values are allowed and which en= tity can allocate them. Is there a registry for these tokens, e.g. an IANA = registry? The editor provided explanation in email, however this was not reflected in= any version of the draft. 2). Section "3.1. Error Codes" I've suggested to use an IANA registry for this field. Apparently there is = already a registry created by .=20 However this document doesn't register values defined in section 3.1 with I= ANA and doesn't point to draft-ietf-oauth-v2-23 for the registry.=20 I find this to be very confusing. Minor issues: none Nits: none _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From turners@ieca.com Wed Apr 11 16:42:13 2012 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 F180E21F84B8 for ; Wed, 11 Apr 2012 16:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhSO6iM1vsUQ for ; Wed, 11 Apr 2012 16:42:12 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [69.93.35.30]) by ietfa.amsl.com (Postfix) with ESMTP id 582A821F8551 for ; Wed, 11 Apr 2012 16:42:12 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id B9FA12EA3482A; Wed, 11 Apr 2012 18:42:11 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id AC1682EA347F0 for ; Wed, 11 Apr 2012 18:42:11 -0500 (CDT) Received: from [71.191.3.52] (port=33351 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SI7Aw-0007HK-RI; Wed, 11 Apr 2012 18:42:11 -0500 Message-ID: <4F8616D1.2080003@ieca.com> Date: Wed, 11 Apr 2012 19:42:09 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436646237B@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436646237B@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-71-191-3-52.washdc.east.verizon.net (thunderfish.local) [71.191.3.52]:33351 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: General Area Review Team , "oauth@ietf.org" , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt 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: Wed, 11 Apr 2012 23:42:13 -0000 On issue 2, Russ has already entered his ballot on the base spec so I'll pick this one up. spt On 4/10/12 8:25 PM, Mike Jones wrote: > Hi Alexey, > > About your issue 1: The OAuth Core spec, where "scope" is primarily defined, includes the sentence "The [scope] strings are defined by the authorization server" (see http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-3.3). I could add that clarification to the Bearer spec as well to make it clear that the scope values are context-dependent, if that would address your concern. > > About your issue 2: Investigating the OAuth Errors Registry a bit further (see http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-11.4.1) while I'd like to be able to register the OAuth Bearer errors in this registry, what I believe to be a defect in the errors registry text currently prevents this. Specifically, the registry enumerates only three "Error usage location" values: authorization code grant error response, implicit grant error response, and token error response. To be able to use this registry, it would also have to have a fourth usage location: "resource access error response". If you'd like to file an issue against the OAuth Core spec to get this additional usage location added to the registry, then I'd be glad to use it. I believe that this would be significantly preferable to adding a separate OAuth Bearer errors registry that's exactly like the general-purpose one, only separate from it. > > Best wishes, > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Alexey Melnikov > Sent: Tuesday, April 10, 2012 7:03 AM > To: draft-ietf-oauth-v2-bearer.all@tools.ietf.org > Cc: General Area Review Team; oauth@ietf.org; The IESG > Subject: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt > > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at. > > Please resolve these comments along with any other Last Call comments you may receive. > Document: draft-ietf-oauth-v2-bearer-18.txt > Reviewer: Alexey Melnikov > Review Date: 10 April 2012 > IETF LC End Date: 7 Feb 2012 > IESG Telechat date: 12 April 2012 > > Summary: Nearly ready to be published as Proposed Standard, with a couple of things that should be addressed or at least discussed. > > Thank you for addressing most of my other issues. However there are a couple remaining which I think are important. > > Major Issues: > > 1). > The "scope" attribute is a space-delimited list of scope values > indicating the required scope of the access token for accessing the > requested resource. In some cases, the "scope" value will be used > when requesting a new access token with sufficient scope of access to > utilize the protected resource. The "scope" attribute MUST NOT > appear more than once. The "scope" value is intended for > programmatic use and is not meant to be displayed to end users. > > I don't think this provide enough information about what this is, how it is to be used and which values are allowed. As this is not meant to be displayed to end users, then you need to say what values are allowed and which entity can allocate them. Is there a registry for these tokens, e.g. an IANA registry? > > The editor provided explanation in email, however this was not reflected in any version of the draft. > > 2). Section "3.1. Error Codes" > > I've suggested to use an IANA registry for this field. Apparently there is already a registry created by. > However this document doesn't register values defined in section 3.1 with IANA and doesn't point to draft-ietf-oauth-v2-23 for the registry. > I find this to be very confusing. > > Minor issues: none > > Nits: none > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > From eran@hueniverse.com Wed Apr 11 20:44:41 2012 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 B661211E80B2; Wed, 11 Apr 2012 20:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92pMGC7quluw; Wed, 11 Apr 2012 20:44:40 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id B336011E80A6; Wed, 11 Apr 2012 20:44:40 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id wrkf1i0010EuLVk01rkf8V; Wed, 11 Apr 2012 20:44:39 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Wed, 11 Apr 2012 20:44:39 -0700 From: Eran Hammer To: Sean Turner Thread-Topic: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt Thread-Index: AQHNGDy+7gVTWsO88kiAN2vkgbM5PZaW912A Date: Thu, 12 Apr 2012 03:44:38 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436646237B@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F8616D1.2080003@ieca.com> In-Reply-To: <4F8616D1.2080003@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <9E1239C5316E6544A94A3AF1737CF0CD@53553.exhost2.secureserver.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: The IESG , General Area Review Team , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt 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: Thu, 12 Apr 2012 03:44:41 -0000 Issue 2 received extensive WG discussion. At the core of it was the question of how the IETF should handle HTTP authe= ntication error codes. We consults with the HTTPbis WG and consensus was th= at at this point we do not want to create a general purpose error registry = for HTTP authentication schemes. In fact, Bearer is the exception using spe= cial error codes which could (and should) just use HTTP 4xx code.=20 While bearer is closely linked to OAuth, it is still a standalone scheme. T= here was no consensus that other schemes (even the OAuth related MAC scheme= ) will sign into such a registry.=20 In short, the OAuth error registry is not an appropriate venue for the bear= er error codes. It is unfortunate that Mr. Jones failed to represent the WG= consensus on this issue in his response to the IESG.=20 EH On Apr 11, 2012, at 19:42, "Sean Turner" wrote: > On issue 2, Russ has already entered his ballot on the base spec so I'll = pick this one up. >=20 > spt >=20 > On 4/10/12 8:25 PM, Mike Jones wrote: >> Hi Alexey, >>=20 >> About your issue 1: The OAuth Core spec, where "scope" is primarily def= ined, includes the sentence "The [scope] strings are defined by the authori= zation server" (see http://tools.ietf.org/html/draft-ietf-oauth-v2-25#secti= on-3.3). I could add that clarification to the Bearer spec as well to make= it clear that the scope values are context-dependent, if that would addres= s your concern. >>=20 >> About your issue 2: Investigating the OAuth Errors Registry a bit furth= er (see http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-11.4.1) w= hile I'd like to be able to register the OAuth Bearer errors in this regist= ry, what I believe to be a defect in the errors registry text currently pre= vents this. Specifically, the registry enumerates only three "Error usage = location" values: authorization code grant error response, implicit grant = error response, and token error response. To be able to use this registry,= it would also have to have a fourth usage location: "resource access erro= r response". If you'd like to file an issue against the OAuth Core spec to= get this additional usage location added to the registry, then I'd be glad= to use it. I believe that this would be significantly preferable to addin= g a separate OAuth Bearer errors registry that's exactly like the general-p= urpose one, only separate from it. >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Alexey Melnikov >> Sent: Tuesday, April 10, 2012 7:03 AM >> To: draft-ietf-oauth-v2-bearer.all@tools.ietf.org >> Cc: General Area Review Team; oauth@ietf.org; The IESG >> Subject: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-beare= r-18.txt >>=20 >> I am the assigned Gen-ART reviewer for this draft. For background on Gen= -ART, please see the FAQ at. >>=20 >> Please resolve these comments along with any other Last Call comments yo= u may receive. >> Document: draft-ietf-oauth-v2-bearer-18.txt >> Reviewer: Alexey Melnikov >> Review Date: 10 April 2012 >> IETF LC End Date: 7 Feb 2012 >> IESG Telechat date: 12 April 2012 >>=20 >> Summary: Nearly ready to be published as Proposed Standard, with a coupl= e of things that should be addressed or at least discussed. >>=20 >> Thank you for addressing most of my other issues. However there are a co= uple remaining which I think are important. >>=20 >> Major Issues: >>=20 >> 1). >> The "scope" attribute is a space-delimited list of scope values >> indicating the required scope of the access token for accessing the >> requested resource. In some cases, the "scope" value will be used >> when requesting a new access token with sufficient scope of access t= o >> utilize the protected resource. The "scope" attribute MUST NOT >> appear more than once. The "scope" value is intended for >> programmatic use and is not meant to be displayed to end users. >>=20 >> I don't think this provide enough information about what this is, how it= is to be used and which values are allowed. As this is not meant to be dis= played to end users, then you need to say what values are allowed and which= entity can allocate them. Is there a registry for these tokens, e.g. an IA= NA registry? >>=20 >> The editor provided explanation in email, however this was not reflected= in any version of the draft. >>=20 >> 2). Section "3.1. Error Codes" >>=20 >> I've suggested to use an IANA registry for this field. Apparently there = is already a registry created by. >> However this document doesn't register values defined in section 3.1 wit= h IANA and doesn't point to draft-ietf-oauth-v2-23 for the registry. >> I find this to be very confusing. >>=20 >> Minor issues: none >>=20 >> Nits: none >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Thu Apr 12 01:54:37 2012 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 5874E21F8665 for ; Thu, 12 Apr 2012 01:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.897 X-Spam-Level: X-Spam-Status: No, score=-103.897 tagged_above=-999 required=5 tests=[AWL=-1.297, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqw6ffPS9lj0 for ; Thu, 12 Apr 2012 01:54:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6EF0321F8661 for ; Thu, 12 Apr 2012 01:54:36 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 08:54:35 -0000 Received: from p57A6EA96.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.234.150] by mail.gmx.net (mp036) with SMTP; 12 Apr 2012 10:54:35 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+jjXw75uijlbuoBXu+sASyCksWPaiMYWSlxOSlFH dW3jrdQkFsDo3a Message-ID: <4F869849.1060508@gmx.de> Date: Thu, 12 Apr 2012 10:54:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Eran Hammer References: <4E1F6AAD24975D4BA5B16804296739436646237B@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F8616D1.2080003@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: General Area Review Team , The IESG , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt 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: Thu, 12 Apr 2012 08:54:37 -0000 Citing from Sean's dicuss (): > 1) I'm hoping the answer to this one is "there's no problem" but I gotta ask and > maybe the APPs ADs can confirm: Is there any issue with this specification > using ABNF from [I-D.ietf-httpbis-p1-messaging] while OAUTH 2.0 uses [RFC5234]? The ABNF from HTTPbis is a superset of RFC 5234 in that it defines a list rule for readability. I don't think that this rule is used anymore in the bearer spec, so it can just say it's using RFC 5234. Best regards, Julian From hannes.tschofenig@gmx.net Thu Apr 12 03:55:12 2012 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 3119721F85DF for ; Thu, 12 Apr 2012 03:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0H5t3Z5bH6h for ; Thu, 12 Apr 2012 03:55:11 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D5EC221F85BD for ; Thu, 12 Apr 2012 03:55:10 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 10:55:09 -0000 Received: from unknown (EHLO [10.255.135.80]) [192.100.123.77] by mail.gmx.net (mp040) with SMTP; 12 Apr 2012 12:55:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+yyscWkFuydmDLlHiVGlUBXzDiA3Li85zH5dBviP t8BtMK9gakaHcN From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Apr 2012 13:55:05 +0300 Message-Id: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Thu, 12 Apr 2012 10:55:12 -0000 Hey guys based on the discussion before, during, and after the Paris IETF meeting = I am going to send the following updated charter / milestones to the = IESG. Please have a quick look (till the end of the week) to double-check the = content (particularly the suggested milestone dates): ---------- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user=20 sharing his or her photo-sharing sites' long-term credential with the=20 printing site.=20 The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server,=20 * a protocol for obtaining authorization tokens from an authorization=20 server with the resource owner's consent,=20 * protocols for presenting these authorization tokens to protected=20 resources for access to a resource, and=20 * consequently for sharing data in a security and privacy respective = way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the=20 completion of OAuth 1.0 the working group started their work on OAuth = 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the = result=20 is available as a stand-alone document offering guidance for audiences=20= beyond the community of protocol implementers. The working group also developed security schemes for presenting = authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access=20= authentication specification.=20 OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH = token with=20 the SAML 2.0 bearer assertion profile. This offers interworking with = existing=20 identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application = service provider=20 community. To build on this success we aim for nothing more than to make = OAuth the=20 authorization framework of choice for any Internet protocol. = Consequently, the=20 ongoing standardization effort within the OAuth working group is focused = on=20 enhancing interoperability of OAuth deployments. While the core OAuth = specification=20 truly is an important building block it relies on other specifications = in order to=20 claim completeness. Luckily, these components already exist and have = been deployed=20 on the Internet. Through the IETF standards process they will be = improved in=20 quality and will undergo a rigorous review process.=20 Goals and Milestones [Editor's Note: Here are the completed items.]=20 Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a = working group item Done Submit 'HTTP Authentication: MAC Authentication' as a working = group item Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for = consideration as a Proposed Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for = consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates = - are they realistic?]=20 May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to = the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for = consideration as a Proposed Standard=20 May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for = consideration as a Proposed Standard=20 May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' = to the IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG = for consideration as a Proposed Standard [Editor's Note: New work for the group] Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as a = Proposed Standard [Starting point for the work will be = http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an = Informational RFC [Starting point for the work will be = http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]=20 Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration = as a Proposed Standard [Starting point for the work will be = http://tools.ietf.org/html/draft-jones-simple-web-discovery]=20 Mar. 2013 Submit 'JSON Web Token (JWT)' to the IESG for consideration = as a Proposed Standard [Starting point for the work will be = http://tools.ietf.org/html/draft-jones-json-web-token] Mar. 2013 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth = 2.0' to the IESG for consideration as a Proposed Standard [Starting point for the work will be = http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the = IESG for consideration as a Proposed Standard [Starting point for the work will be = http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]=20 From hannes.tschofenig@gmx.net Thu Apr 12 04:00:20 2012 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 E0B0721F8609 for ; Thu, 12 Apr 2012 04:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne0nbwqdCZKK for ; Thu, 12 Apr 2012 04:00:20 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2AD7021F8615 for ; Thu, 12 Apr 2012 04:00:18 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 11:00:12 -0000 Received: from unknown (EHLO [10.255.135.80]) [192.100.123.77] by mail.gmx.net (mp020) with SMTP; 12 Apr 2012 13:00:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+EnyEyy7WEi8Qd2/1edSG+JZHLuand2kw4B6Thmo muUDjtMR/gOgWc From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Apr 2012 14:00:07 +0300 Message-Id: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 12 Apr 2012 11:00:21 -0000 Hi all,=20 those who had attended the last IETF meeting may have noticed the = ongoing activity in the 'Applications Area Working Group' regarding Web = Finger.=20 We had our discussion regarding Simple Web Discovery (SWD) as part of = the re-chartering process.=20 Here are the two specifications: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 Now, the questions that seems to be hanging around are 1) Aren't these two mechanisms solving pretty much the same problem? 2) Do we need to have two standards for the same functionality? 3) Do you guys have a position or comments regarding either one of = them?=20 Ciao Hannes PS: Please also let me know if your view is: "I don't really know what = all this is about and the documents actually don't provide enough = requirements to make a reasonable judgement about the solution space." From alexey.melnikov@isode.com Thu Apr 12 04:21:43 2012 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 4A20021F85D2; Thu, 12 Apr 2012 04:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foCJl+6xzN2V; Thu, 12 Apr 2012 04:21:41 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id F10E921F85D1; Thu, 12 Apr 2012 04:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334229699; d=isode.com; s=selector; i=@isode.com; bh=S7YOLNgfjxY2v/2AcHrHUWHnO5Cu9VZ/AvAY08aBh2A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=B+gKdxnkQ0KKmNs8b8c3aAkqSKmwgrE3kAq+h+S5+YVL95xEdDsfMxY2bSBjKMWpBu7fOF kjm4pfgnAntnFFk76mkSbS2R2UgPgJYACt5KmMln+hdwHMJSAH9bdfMm6p661xjT7oD4xn ENerZ3Riu4gwbP9LragMqw0zg/p62VE=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 12 Apr 2012 12:21:39 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F86BAE9.4000406@isode.com> Date: Thu, 12 Apr 2012 12:22:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436646237B@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436646237B@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: General Area Review Team , Russ Housley , "oauth@ietf.org" , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt 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: Thu, 12 Apr 2012 11:21:44 -0000 On 11/04/2012 01:25, Mike Jones wrote: > Hi Alexey, Hi Mike, I've dropped issue 2, Sean took charge of discussing it with IESG. > About your issue 1: The OAuth Core spec, where "scope" is primarily defined, includes the sentence "The [scope] strings are defined by the authorization server" (see http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-3.3). I could add that clarification to the Bearer spec as well to make it clear that the scope values are context-dependent, if that would address your concern. Yes, but only partially. I would also like to see a clear statement that there is no centralized registry for scope values, plus some examples (more than 1) of how values of this attribute can look like. With out this information I don't think the spec is implementable. From michiel@unhosted.org Thu Apr 12 04:45:34 2012 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 CBA9021F8636 for ; Thu, 12 Apr 2012 04:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Opac3EySLu6R for ; Thu, 12 Apr 2012 04:45:34 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id ECA9921F8629 for ; Thu, 12 Apr 2012 04:45:33 -0700 (PDT) Received: by dady13 with SMTP id y13so3322865dad.27 for ; Thu, 12 Apr 2012 04:45:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=RIpEXVDNZte4w7V6r1L803HqZQ13rH8PIZFazklD1z8=; b=UaWO3D9Jq+VvVPDl2vseCthIFVGS7JDmlm6W69tuwxfG0vSno+REWPrCuEUWo4OnyV e/kEP9pCbu9vovJGvCMeJvA5uIn79OvCd3WYjEyHaMwnyzj25piY7jhxKZCPmXR25pM/ 5EiRVXRzj1jQsFh3QgBxCHDJ5M4CBC5tNREx5q/277drkjF3UvAibV7uLmvTg09C/qag UImBMz2hSliOEjVgxvLCP+xbIKY/yjfpnE0lLTplYSFAbVam7KZ4FuOucPKu22vkYJiq 1vk+u8GgyjGAp5cu3O3Pjo8UHt40RKEczZjr1NSNNIC0K30BrzJLqsehkfN5T9aNLRFY hrJQ== MIME-Version: 1.0 Received: by 10.68.200.162 with SMTP id jt2mr2449369pbc.54.1334231133738; Thu, 12 Apr 2012 04:45:33 -0700 (PDT) Received: by 10.68.25.132 with HTTP; Thu, 12 Apr 2012 04:45:33 -0700 (PDT) X-Originating-IP: [77.188.19.113] In-Reply-To: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> Date: Thu, 12 Apr 2012 13:45:33 +0200 Message-ID: From: Michiel de Jong To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmQuvMl8EwFISyioOaT3F6EbmrWDkUxkkzKQGzl9HuVUceVouJIKN1qqScE6M5b/bREOt3H Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 12 Apr 2012 11:45:34 -0000 Kudos for bringing this up! imho, "speccers gonna spec" and it's impossible to stop overlapping specs from showing up all the time. we'll have to live with the existence of multiple standards. Clients will just have to stand above whatever political reasons lie behind them, and support both, just like DVD players often play like 8 different types of disc formats. We'll just have to query both, and merge the information we find. There are three important points regarding the differences between them, im= ho: - webfinger mentions CORS, meaning that unlike swd it can be queried by unhosted html5 apps, and not just server-to-server. - swd mentions 401 responses, meaning that unlike webfinger, it can be used to announce information to a limited audience, and not just public data. - webfinger starts at /.well-known/host-meta but swd starts at /.well-known/simple-web-discovery, meaning a relying party will have to choose which one to check first, and then check the other one in case additional information lurks there. It would be nice if at least that part could be reconciled. E.g. if swd requires providers to (also) be discoverable through host-meta. That way there's one entry point for both formats. Wouldn't that be nice? My 2ct, Michiel. On Thu, Apr 12, 2012 at 1:00 PM, Hannes Tschofenig wrote: > Hi all, > > those who had attended the last IETF meeting may have noticed the ongoing= activity in the 'Applications Area Working Group' regarding Web Finger. > We had our discussion regarding Simple Web Discovery (SWD) as part of the= re-chartering process. > > Here are the two specifications: > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 > > Now, the questions that seems to be hanging around are > > =A01) Aren't these two mechanisms solving pretty much the same problem? > =A02) Do we need to have two standards for the same functionality? > =A03) Do you guys have a position or comments regarding either one of the= m? > > Ciao > Hannes > > PS: Please also let me know if your view is: "I don't really know what al= l this is about and the documents actually don't provide enough requirement= s to make a reasonable judgement about the solution space." > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stephen.farrell@cs.tcd.ie Thu Apr 12 05:02:04 2012 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 51C6E21F85A3; Thu, 12 Apr 2012 05:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVWCEWHgnza6; Thu, 12 Apr 2012 05:02:03 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C92B21F84B8; Thu, 12 Apr 2012 05:02:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 03CD317147D; Thu, 12 Apr 2012 13:02:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334232120; bh=0hhJx339BfR99P Ll1NZFG4gOklDtxqctzoHczcMrAe0=; b=K0lLb3kFAcvmUon0d8x3Gc4B1OGUGi fIERPG0yeqetw4LEPV6wkq3shTpu+CoByT13bpLLU6BTW3dar1iioTPHm3WOIWJt ufImCG631VXFFzcDzgG/AkbGO4TNx6tcIgqFnxiRoB/dXqGGGEIqMu0UrxCTR0E8 6sG8PWl1vV50pfJfU0WDU5ZwTieiHaDrvPaeWHZ3l53hmLCrvZuMbH76uuijFtUy oMvEZqGLxhXNjNMt/EcOfQ03sVvNkR2DD1UDWcIuSY9Qqv1bxOsMsm45M+Z8vUQm EGeEvoY6TFgtva9WJeWm0LeC9H0VRq2jDNgL9Uj8rxfQ9IwdYjUVJlPw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 1IXcjoiVrK-H; Thu, 12 Apr 2012 13:02:00 +0100 (IST) Received: from [10.87.48.3] (unknown [86.45.63.74]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 56A6117147C; Thu, 12 Apr 2012 13:02:00 +0100 (IST) Message-ID: <4F86C437.3000006@cs.tcd.ie> Date: Thu, 12 Apr 2012 13:01:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> In-Reply-To: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 12 Apr 2012 12:02:04 -0000 On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: > Hi all, > > those who had attended the last IETF meeting may have noticed the ongoing activity in the 'Applications Area Working Group' regarding Web Finger. > We had our discussion regarding Simple Web Discovery (SWD) as part of the re-chartering process. > > Here are the two specifications: > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 > > Now, the questions that seems to be hanging around are > > 1) Aren't these two mechanisms solving pretty much the same problem? > 2) Do we need to have two standards for the same functionality? > 3) Do you guys have a position or comments regarding either one of them? > > Ciao > Hannes > > PS: Please also let me know if your view is: "I don't really know what all this is about and the documents actually don't provide enough requirements to make a reasonable judgement about the solution space." > So just as a data-point. We (the IETF, but including me personally;-) mucked up badly on this some years ago in the PKI space - we standardised both CMP (rfc 2510) and CMC (rfc 2797) as two ways to do the same thing, after a protracted battle between factions supporting one or the other. We even made sure they had as much common syntax as possible. (CRMF, rfc 2511) Result: neither fully adopted, lots of people still do proprietary stuff, neither can be killed off (despite attempts), both need to be maintained (CMP is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO partly as a result of us screwing up for what seemed like good reasons at the time, PKI administration stuff has never gotten beyond horrible-to-do. All-in-all, a really bad outcome which is still a PITA a dozen years later. As OAuth AD I will need *serious* convincing that there is a need to provide two ways to do the same thing. I doubt it'll be possible to convince me, in fact, so if you wanna try, you'll need to start by saying that they are not in fact two ways to do the same thing:-) S. PS: This discussion needs to also involve the Apps area, so I've cc'd that list. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Thu Apr 12 05:38:31 2012 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 40F0821F8647 for ; Thu, 12 Apr 2012 05:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TacokvyWb2jV for ; Thu, 12 Apr 2012 05:38:30 -0700 (PDT) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 38DBB21F8646 for ; Thu, 12 Apr 2012 05:38:30 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id x0eV1i0050CJzpC010eVCo; Thu, 12 Apr 2012 05:38:29 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Thu, 12 Apr 2012 05:38:29 -0700 From: Eran Hammer To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Updated Charter to the IESG (this weekend) Thread-Index: AQHNGJq/GjuWXf3fNE+kECT0HKbvUJaXIRtf Date: Thu, 12 Apr 2012 12:38:29 +0000 Message-ID: References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> In-Reply-To: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Thu, 12 Apr 2012 12:38:31 -0000 With the exception of SWD which is still being discussed, this looks good.= =20 EH On Apr 12, 2012, at 6:55, "Hannes Tschofenig" w= rote: > Hey guys >=20 > based on the discussion before, during, and after the Paris IETF meeting = I am going to send the following updated charter / milestones to the IESG. > Please have a quick look (till the end of the week) to double-check the c= ontent (particularly the suggested milestone dates): >=20 > ---------- >=20 >=20 > Web Authorization Protocol (oauth) >=20 > Description of Working Group >=20 > The Web Authorization (OAuth) protocol allows a user to grant > a third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that supports > OAuth could allow its users to use a third-party printing Web site to > print their private pictures, without allowing the printing site to > gain full control of the user's account and without having the user=20 > sharing his or her photo-sharing sites' long-term credential with the=20 > printing site.=20 >=20 > The OAuth protocol suite encompasses > * a procedure for allowing a client to discover a resource server,=20 > * a protocol for obtaining authorization tokens from an authorization=20 > server with the resource owner's consent,=20 > * protocols for presenting these authorization tokens to protected=20 > resources for access to a resource, and=20 > * consequently for sharing data in a security and privacy respective way. >=20 > In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, > was published as an informational document (RFC 5849). With the=20 > completion of OAuth 1.0 the working group started their work on OAuth 2.0 > to incorporate implementation experience with version 1.0, additional > use cases, and various other security, readability, and interoperability > improvements. An extensive security analysis was conducted and the result= =20 > is available as a stand-alone document offering guidance for audiences=20 > beyond the community of protocol implementers. >=20 > The working group also developed security schemes for presenting authoriz= ation > tokens to access a protected resource. This led to the publication of > the bearer token as well as the message authentication code (MAC) access= =20 > authentication specification.=20 >=20 > OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH to= ken with=20 > the SAML 2.0 bearer assertion profile. This offers interworking with exi= sting=20 > identity management solutions, in particular SAML based deployments. >=20 > OAuth has enjoyed widespread adoption by the Internet application service= provider=20 > community. To build on this success we aim for nothing more than to make = OAuth the=20 > authorization framework of choice for any Internet protocol. Consequently= , the=20 > ongoing standardization effort within the OAuth working group is focused = on=20 > enhancing interoperability of OAuth deployments. While the core OAuth spe= cification=20 > truly is an important building block it relies on other specifications in= order to=20 > claim completeness. Luckily, these components already exist and have been= deployed=20 > on the Internet. Through the IETF standards process they will be improved= in=20 > quality and will undergo a rigorous review process.=20 >=20 > Goals and Milestones >=20 > [Editor's Note: Here are the completed items.]=20 >=20 > Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a wo= rking group item > Done Submit 'HTTP Authentication: MAC Authentication' as a working group= item > Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for cons= ideration as a Proposed Standard > Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consi= deration as a Proposed Standard >=20 > [Editor's Note: Finishing existing work. Double-check the proposed dates = - are they realistic?]=20 >=20 > May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to t= he IESG for consideration as a Proposed Standard > May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for considera= tion as a Proposed Standard=20 > May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for c= onsideration as a Proposed Standard=20 > May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to= the IESG for consideration as an Informational RFC > Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG f= or consideration as a Proposed Standard >=20 > [Editor's Note: New work for the group] >=20 > Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as a P= roposed Standard >=20 > [Starting point for the work will be http://datatracker.ietf.org/doc/draf= t-lodderstedt-oauth-revocation/] >=20 > Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an I= nformational RFC >=20 > [Starting point for the work will be http://tools.ietf.org/html/draft-zel= tsan-oauth-use-cases]=20 >=20 > Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration as= a Proposed Standard >=20 > [Starting point for the work will be http://tools.ietf.org/html/draft-jon= es-simple-web-discovery]=20 >=20 > Mar. 2013 Submit 'JSON Web Token (JWT)' to the IESG for consideration as= a Proposed Standard >=20 > [Starting point for the work will be http://tools.ietf.org/html/draft-jon= es-json-web-token] >=20 > Mar. 2013 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2= .0' to the IESG for consideration as a Proposed Standard >=20 > [Starting point for the work will be http://tools.ietf.org/html/draft-jon= es-oauth-jwt-bearer] >=20 > Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IES= G for consideration as a Proposed Standard >=20 > [Starting point for the work will be http://tools.ietf.org/html/draft-har= djono-oauth-dynreg]=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Thu Apr 12 06:27:24 2012 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 4288921F848C for ; Thu, 12 Apr 2012 06:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGo8T27mdiYy for ; Thu, 12 Apr 2012 06:27:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5A8A221F848E for ; Thu, 12 Apr 2012 06:27:23 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 13:27:22 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp071) with SMTP; 12 Apr 2012 15:27:22 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX193xHMS4aB3fFeEvCqwQj7noTY5I/LVTZdIGqsvvt ai4/Iy+ghzUMzz Message-ID: <4F86D836.1000007@gmx.de> Date: Thu, 12 Apr 2012 15:27:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F27C37C.1090008@isode.com> <4F843A22.4020908@isode.com> <4F843DA1.8080703@isode.com> In-Reply-To: <4F843DA1.8080703@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: General Area Review Team , "oauth@ietf.org" , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , The IESG Subject: [OAUTH-WG] where do error codes go?, was: Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt 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: Thu, 12 Apr 2012 13:27:24 -0000 On 2012-04-10 16:03, Alexey Melnikov wrote: > ... > 2). Section "3.1. Error Codes" > > I've suggested to use an IANA registry for this field. Apparently there > is already a registry created by > . > However this document doesn't register values defined in section 3.1 > with IANA and doesn't point to draft-ietf-oauth-v2-23 for the registry. > I find this to be very confusing. > ... Speaking of which, how is an error code returned if the HTTP status is *not* 401? 3.1. Error Codes When a request fails, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405), and includes one of the following error codes in the response: invalid_request The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed. The resource server SHOULD respond with the HTTP 400 (Bad Request) status code. ... Is the assumption that the response body is always application/json in that case? It might be good to clarify that. Best regards, Julian From paul.madsen@gmail.com Thu Apr 12 07:37:45 2012 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 147CF21F85F4 for ; Thu, 12 Apr 2012 07:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPxpzCXdR5m7 for ; Thu, 12 Apr 2012 07:37:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF26F21F85F9 for ; Thu, 12 Apr 2012 07:37:43 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3268309obb.31 for ; Thu, 12 Apr 2012 07:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=qis30D/EFhUvLvPlLI4RN11lZ1XoGVhq13oT6SfNbFM=; b=RALW7hbgzUGYW5p0mnVvpfoqKn09J6DRGUhzICZDY2DRM4KH5N65WUezlVjHt0KaNf 5uij5mkMawOfBUWQvjchV3dLID2arGz7kLYbexs0cd7/oqNG2DkQLYAKBVbmgthB+KGU o90F3h21CkkObvYQuxVTLilFlgXhes8Dm6DyXguY3/0C5KXETk21jg2ltjAvj/cIMRBC NRx2qbdC7aEmjNCFRyWtQx+mAE1AbrjE4mHZAfN9OQ3cTbHyUzObfmCGIXLfssS5ea9w 99OsHLn8iJlz3Ft06NbYqJloGv69qeVxCRAmfeaR1pzTNECtaNFv7g6P6eJfRkC5Yidp SvvA== Received: by 10.182.225.2 with SMTP id rg2mr3479900obc.2.1334241463379; Thu, 12 Apr 2012 07:37:43 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.162.33]) by mx.google.com with ESMTPS id il8sm6866946obc.18.2012.04.12.07.37.36 (version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 07:37:37 -0700 (PDT) Message-ID: <4F86E8AF.1030601@gmail.com> Date: Thu, 12 Apr 2012 10:37:35 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Hannes Tschofenig References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> In-Reply-To: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> Content-Type: multipart/alternative; boundary="------------060306090003070101050203" Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Thu, 12 Apr 2012 14:37:45 -0000 This is a multi-part message in MIME format. --------------060306090003070101050203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes, do you mean 'discover relevant OAuth endpoints *for* a resource server'? ie instead of discovering the RS itself? On 4/12/12 6:55 AM, Hannes Tschofenig wrote: > Hey guys > > based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. > Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): > > ---------- > > > Web Authorization Protocol (oauth) > > Description of Working Group > > The Web Authorization (OAuth) protocol allows a user to grant > a third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that supports > OAuth could allow its users to use a third-party printing Web site to > print their private pictures, without allowing the printing site to > gain full control of the user's account and without having the user > sharing his or her photo-sharing sites' long-term credential with the > printing site. > > The OAuth protocol suite encompasses > * a procedure for allowing a client to discover a resource server, > * a protocol for obtaining authorization tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these authorization tokens to protected > resources for access to a resource, and > * consequently for sharing data in a security and privacy respective way. > > In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, > was published as an informational document (RFC 5849). With the > completion of OAuth 1.0 the working group started their work on OAuth 2.0 > to incorporate implementation experience with version 1.0, additional > use cases, and various other security, readability, and interoperability > improvements. An extensive security analysis was conducted and the result > is available as a stand-alone document offering guidance for audiences > beyond the community of protocol implementers. > > The working group also developed security schemes for presenting authorization > tokens to access a protected resource. This led to the publication of > the bearer token as well as the message authentication code (MAC) access > authentication specification. > > OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with > the SAML 2.0 bearer assertion profile. This offers interworking with existing > identity management solutions, in particular SAML based deployments. > > OAuth has enjoyed widespread adoption by the Internet application service provider > community. To build on this success we aim for nothing more than to make OAuth the > authorization framework of choice for any Internet protocol. Consequently, the > ongoing standardization effort within the OAuth working group is focused on > enhancing interoperability of OAuth deployments. While the core OAuth specification > truly is an important building block it relies on other specifications in order to > claim completeness. Luckily, these components already exist and have been deployed > on the Internet. Through the IETF standards process they will be improved in > quality and will undergo a rigorous review process. > > Goals and Milestones > > [Editor's Note: Here are the completed items.] > > Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item > Done Submit 'HTTP Authentication: MAC Authentication' as a working group item > Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard > Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard > > [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] > > May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard > May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard > May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard > May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC > Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard > > [Editor's Note: New work for the group] > > Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] > > Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC > > [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] > > Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-jones-simple-web-discovery] > > Mar. 2013 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token] > > Mar. 2013 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] > > Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------060306090003070101050203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Hannes, do you mean 'discover relevant OAuth endpoints *for* a resource server'? ie instead of discovering the RS itself?

On 4/12/12 6:55 AM, Hannes Tschofenig wrote: 
Hey guys

based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG.
Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates):

----------


Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user 
sharing his or her photo-sharing sites' long-term credential with the 
printing site. 

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server, 
* a protocol for obtaining authorization tokens from an authorization 
server with the resource owner's consent, 
* protocols for presenting these authorization tokens to protected 
resources for access to a resource, and 
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the 
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result 
is available as a stand-alone document offering guidance for audiences 
beyond the community of protocol implementers.

The working group also developed security schemes for presenting authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access 
authentication specification. 

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with 
the SAML 2.0 bearer assertion profile.  This offers interworking with existing 
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application service provider 
community. To build on this success we aim for nothing more than to make OAuth the 
authorization framework of choice for any Internet protocol. Consequently, the 
ongoing standardization effort within the OAuth working group is focused on 
enhancing interoperability of OAuth deployments. While the core OAuth specification 
truly is an important building block it relies on other specifications in order to 
claim completeness. Luckily, these components already exist and have been deployed 
on the Internet. Through the IETF standards process they will be improved in 
quality and will undergo a rigorous review process. 

Goals and Milestones

[Editor's Note: Here are the completed items.] 

Done  Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item
Done  Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done  Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard
Done  Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] 

May  2012  Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
May  2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard 
May  2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard 
May  2012  Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC
Dec. 2012  Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard

[Editor's Note: New work for the group]

Nov. 2012  Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Dec. 2012  Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC

[Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] 

Jan. 2013  Submit 'Simple Web Discovery' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones-simple-web-discovery] 

Mar. 2013  Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]

Mar. 2013  Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

Jul. 2013  Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------060306090003070101050203-- From igor.faynberg@alcatel-lucent.com Thu Apr 12 09:57:54 2012 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 4F19621F86C7 for ; Thu, 12 Apr 2012 09:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7fn7Mk88Q8n for ; Thu, 12 Apr 2012 09:57:53 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8150A21F8585 for ; Thu, 12 Apr 2012 09:57:52 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q3CGvnHS024813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 12 Apr 2012 11:57:49 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3CGvn5R015330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Apr 2012 11:57:49 -0500 Received: from [135.222.232.147] (USMUYN0L055118.mh.lucent.com [135.222.232.147]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3CGvmEG016419; Thu, 12 Apr 2012 11:57:48 -0500 (CDT) Message-ID: <4F87098C.7070408@alcatel-lucent.com> Date: Thu, 12 Apr 2012 12:57:48 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> In-Reply-To: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:57:54 -0000 Hannes, I took a look (a bit longer than just "quick"), and what I see completely coincides with my understanding of the result of the discussions. Good job! Igor On 4/12/2012 6:55 AM, Hannes Tschofenig wrote: > Hey guys > > based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. > Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): > > ---------- > > > Web Authorization Protocol (oauth) > > Description of Working Group > > The Web Authorization (OAuth) protocol allows a user to grant > a third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that supports > OAuth could allow its users to use a third-party printing Web site to > print their private pictures, without allowing the printing site to > gain full control of the user's account and without having the user > sharing his or her photo-sharing sites' long-term credential with the > printing site. > > The OAuth protocol suite encompasses > * a procedure for allowing a client to discover a resource server, > * a protocol for obtaining authorization tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these authorization tokens to protected > resources for access to a resource, and > * consequently for sharing data in a security and privacy respective way. > > In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, > was published as an informational document (RFC 5849). With the > completion of OAuth 1.0 the working group started their work on OAuth 2.0 > to incorporate implementation experience with version 1.0, additional > use cases, and various other security, readability, and interoperability > improvements. An extensive security analysis was conducted and the result > is available as a stand-alone document offering guidance for audiences > beyond the community of protocol implementers. > > The working group also developed security schemes for presenting authorization > tokens to access a protected resource. This led to the publication of > the bearer token as well as the message authentication code (MAC) access > authentication specification. > > OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with > the SAML 2.0 bearer assertion profile. This offers interworking with existing > identity management solutions, in particular SAML based deployments. > > OAuth has enjoyed widespread adoption by the Internet application service provider > community. To build on this success we aim for nothing more than to make OAuth the > authorization framework of choice for any Internet protocol. Consequently, the > ongoing standardization effort within the OAuth working group is focused on > enhancing interoperability of OAuth deployments. While the core OAuth specification > truly is an important building block it relies on other specifications in order to > claim completeness. Luckily, these components already exist and have been deployed > on the Internet. Through the IETF standards process they will be improved in > quality and will undergo a rigorous review process. > > Goals and Milestones > > [Editor's Note: Here are the completed items.] > > Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item > Done Submit 'HTTP Authentication: MAC Authentication' as a working group item > Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard > Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard > > [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] > > May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard > May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard > May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard > May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC > Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard > > [Editor's Note: New work for the group] > > Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] > > Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC > > [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] > > Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-jones-simple-web-discovery] > > Mar. 2013 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token] > > Mar. 2013 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] > > Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Thu Apr 12 10:33:57 2012 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 C2A0821F8692 for ; Thu, 12 Apr 2012 10:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lkI8h8dqLTj for ; Thu, 12 Apr 2012 10:33:56 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BF7AB21F8661 for ; Thu, 12 Apr 2012 10:33:56 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q3CHXsuF024554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 12 Apr 2012 12:33:54 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3CHXsEf012728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Apr 2012 12:33:54 -0500 Received: from [135.222.232.147] (USMUYN0L055118.mh.lucent.com [135.222.232.147]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3CHXrQ3008637; Thu, 12 Apr 2012 12:33:53 -0500 (CDT) Message-ID: <4F871201.1000103@alcatel-lucent.com> Date: Thu, 12 Apr 2012 13:33:53 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F86C437.3000006@cs.tcd.ie> In-Reply-To: <4F86C437.3000006@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 17:33:58 -0000 To me this looks like more than the same problem being solved--it appears to be the same protocol... I wonder if, the representation issues were put aside (i.e., left to the API specification), the common part is what can be adopted. Igor On 4/12/2012 8:01 AM, Stephen Farrell wrote: > > > On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: > > Hi all, > > > > those who had attended the last IETF meeting may have noticed the > ongoing activity in the 'Applications Area Working Group' regarding > Web Finger. > > We had our discussion regarding Simple Web Discovery (SWD) as part > of the re-chartering process. > > > > Here are the two specifications: > > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 > > > > Now, the questions that seems to be hanging around are > > > > 1) Aren't these two mechanisms solving pretty much the same problem? > > 2) Do we need to have two standards for the same functionality? > > 3) Do you guys have a position or comments regarding either one of > them? > > > > Ciao > > Hannes > > > > PS: Please also let me know if your view is: "I don't really know > what all this is about and the documents actually don't provide enough > requirements to make a reasonable judgement about the solution space." > > > > So just as a data-point. We (the IETF, but including > me personally;-) mucked up badly on this some years > ago in the PKI space - we standardised both CMP (rfc > 2510) and CMC (rfc 2797) as two ways to do the same > thing, after a protracted battle between factions > supporting one or the other. We even made sure they > had as much common syntax as possible. (CRMF, rfc > 2511) > > Result: neither fully adopted, lots of people still > do proprietary stuff, neither can be killed off > (despite attempts), both need to be maintained (CMP > is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO > partly as a result of us screwing up for what seemed > like good reasons at the time, PKI administration > stuff has never gotten beyond horrible-to-do. > > All-in-all, a really bad outcome which is still > a PITA a dozen years later. > > As OAuth AD I will need *serious* convincing that > there is a need to provide two ways to do the same > thing. I doubt it'll be possible to convince me, > in fact, so if you wanna try, you'll need to start > by saying that they are not in fact two ways to do > the same thing:-) > > S. > > PS: This discussion needs to also involve the Apps > area, so I've cc'd that list. > >> >> >> >> _______________________________________________ >> 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 From ve7jtb@ve7jtb.com Thu Apr 12 11:01:01 2012 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 E6D0921F85F9 for ; Thu, 12 Apr 2012 11:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69wepcywVxUZ for ; Thu, 12 Apr 2012 11:01:01 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB83E21F85EF for ; Thu, 12 Apr 2012 11:01:00 -0700 (PDT) Received: by eeke51 with SMTP id e51so614980eek.31 for ; Thu, 12 Apr 2012 11:00:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=UI8aEAr8UI3uamkG9BSgSqH4PqHysfQxDHa2DQFzf8A=; b=ZevXvANFW4jYNUw3Fo/zRzZ3NSXT2XHg813JZDNSGYD2iQfvc4Ynd0yO8Ddz4B3cFf NyW0oi1JKVbpeUwGp0c9D+yS0j7rw89ikcc1Jx4Y5XdfpSKB/Z7akjc8CyJ247GFtDHN xlhhicZa7AZOBQcgg9GO+eXyI2ZZD8gdJv9L72d907tPlc4HKVD/ZvH7uHHjkeGjAPca sQ4xLt0noVMb/4u/CMyjxHExq4vgZUeNkuoxgYetK7i17vHPVC0xDslBLLboEUqH2pxK UUH3nrm2qJRsWX61UYOXE3RkzZxZ1SsU1YjqYm1Iavi74o3J00BCIu3RNp832KFQrrSb Ib8Q== Received: by 10.213.105.70 with SMTP id s6mr284239ebo.45.1334253659510; Thu, 12 Apr 2012 11:00:59 -0700 (PDT) Received: from [10.0.10.185] ([212.144.56.68]) by mx.google.com with ESMTPS id n56sm31021692eeb.4.2012.04.12.11.00.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 11:00:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_14236A3C-32AD-4ADA-9499-A22CBC6C9AA0"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4F871201.1000103@alcatel-lucent.com> Date: Thu, 12 Apr 2012 20:00:55 +0200 Message-Id: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F86C437.3000006@cs.tcd.ie> <4F871201.1000103@alcatel-lucent.com> To: igor.faynberg@alcatel-lucent.com X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmuoElMWOqO0A0+bCW0KL1QI3F4XrQ/jGfM62ts0wCMTSWvtzBGqU3L6bTeznREsXYAFrQu Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 12 Apr 2012 18:01:02 -0000 --Apple-Mail=_14236A3C-32AD-4ADA-9499-A22CBC6C9AA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There are important deployment and privacy issues that caused openID = Connect to use SWD. I was part of the OASIS XRI/XRD work that Web Finger has been based on. The main differences are around allowing all of the users information to = be publicly discoverable, vs providing for access control.=20 They are similar, but have real design differences. Web Finger without XML is not horrible by any means, but nether is SWD. SWD is more about users while host-meta is more about server resources. John B. On 2012-04-12, at 7:33 PM, Igor Faynberg wrote: > To me this looks like more than the same problem being solved--it = appears to be the same protocol... I wonder if, the representation = issues were put aside (i.e., left to the API specification), the common = part is what can be adopted. >=20 > Igor >=20 > On 4/12/2012 8:01 AM, Stephen Farrell wrote: >>=20 >>=20 >> On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: >> > Hi all, >> > >> > those who had attended the last IETF meeting may have noticed the = ongoing activity in the 'Applications Area Working Group' regarding Web = Finger. >> > We had our discussion regarding Simple Web Discovery (SWD) as part = of the re-chartering process. >> > >> > Here are the two specifications: >> > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 >> > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 >> > >> > Now, the questions that seems to be hanging around are >> > >> > 1) Aren't these two mechanisms solving pretty much the same = problem? >> > 2) Do we need to have two standards for the same functionality? >> > 3) Do you guys have a position or comments regarding either one = of them? >> > >> > Ciao >> > Hannes >> > >> > PS: Please also let me know if your view is: "I don't really know = what all this is about and the documents actually don't provide enough = requirements to make a reasonable judgement about the solution space." >> > >>=20 >> So just as a data-point. We (the IETF, but including >> me personally;-) mucked up badly on this some years >> ago in the PKI space - we standardised both CMP (rfc >> 2510) and CMC (rfc 2797) as two ways to do the same >> thing, after a protracted battle between factions >> supporting one or the other. We even made sure they >> had as much common syntax as possible. (CRMF, rfc >> 2511) >>=20 >> Result: neither fully adopted, lots of people still >> do proprietary stuff, neither can be killed off >> (despite attempts), both need to be maintained (CMP >> is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO >> partly as a result of us screwing up for what seemed >> like good reasons at the time, PKI administration >> stuff has never gotten beyond horrible-to-do. >>=20 >> All-in-all, a really bad outcome which is still >> a PITA a dozen years later. >>=20 >> As OAuth AD I will need *serious* convincing that >> there is a need to provide two ways to do the same >> thing. I doubt it'll be possible to convince me, >> in fact, so if you wanna try, you'll need to start >> by saying that they are not in fact two ways to do >> the same thing:-) >>=20 >> S. >>=20 >> PS: This discussion needs to also involve the Apps >> area, so I've cc'd that list. >>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >> _______________________________________________ >> 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 --Apple-Mail=_14236A3C-32AD-4ADA-9499-A22CBC6C9AA0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx MjE4MDA1NlowIwYJKoZIhvcNAQkEMRYEFN3X3rq+Aej69sYZmbAcIxsVTOm9MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ABr2n8S295EQQ+PuVbi844X37s0zjG/x6xvAIe0XfiePy3eQQKzbl9MMHKcNATLt0FpINJKp5wFf kw1WLg0CGEcLMXruay1Ve6F/tttNuFSGin0XkkfXasLyuNl+Fnw8a798mPb5TWrjUxaEEhH57z74 B6XWtstNMeMsI2HjzOFksZciWCtCywomz9RAEz+o6LGC8krShChOXXDFoBGlfyJ52RFU5E865flJ 3meRrS2mbH9ha70Lsq6qsmo8yqdWgywZMcume4GqIJLzjPg7hqBAa3QR0+cZA3plM81D9j5/Bicv MX30KvaKbzRjxfzwJyIP9hFt3mdulFOqTVnPssAAAAAAAAA= --Apple-Mail=_14236A3C-32AD-4ADA-9499-A22CBC6C9AA0-- From eran@hueniverse.com Thu Apr 12 11:18:10 2012 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 C463221F85F8 for ; Thu, 12 Apr 2012 11:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcYkxTCTJvRX for ; Thu, 12 Apr 2012 11:18:10 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 074A621F85BD for ; Thu, 12 Apr 2012 11:18:10 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id x6J91i0020EuLVk016J9mF; Thu, 12 Apr 2012 11:18:09 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Thu, 12 Apr 2012 11:18:09 -0700 From: Eran Hammer To: John Bradley Thread-Topic: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNGJt1/+q3DOFEzk6CK4fFAhsGypaXjEKAgABcu4CAAAeOgP//j3cH Date: Thu, 12 Apr 2012 18:18:08 +0000 Message-ID: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F86C437.3000006@cs.tcd.ie> <4F871201.1000103@alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 12 Apr 2012 18:18:10 -0000 Where is this access control and user centric architecture described? I cou= ld not find it.=20 EH On Apr 12, 2012, at 14:01, "John Bradley" wrote: > There are important deployment and privacy issues that caused openID Conn= ect to use SWD. >=20 > I was part of the OASIS XRI/XRD work that Web Finger has been based on. >=20 > The main differences are around allowing all of the users information to = be publicly discoverable, vs providing for access control.=20 >=20 > They are similar, but have real design differences. >=20 > Web Finger without XML is not horrible by any means, but nether is SWD. >=20 > SWD is more about users while host-meta is more about server resources. >=20 > John B. >=20 >=20 > On 2012-04-12, at 7:33 PM, Igor Faynberg wrote: >=20 >> To me this looks like more than the same problem being solved--it appear= s to be the same protocol... I wonder if, the representation issues were pu= t aside (i.e., left to the API specification), the common part is what can = be adopted. >>=20 >> Igor >>=20 >> On 4/12/2012 8:01 AM, Stephen Farrell wrote: >>>=20 >>>=20 >>> On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: >>>> Hi all, >>>>=20 >>>> those who had attended the last IETF meeting may have noticed the ongo= ing activity in the 'Applications Area Working Group' regarding Web Finger. >>>> We had our discussion regarding Simple Web Discovery (SWD) as part of = the re-chartering process. >>>>=20 >>>> Here are the two specifications: >>>> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 >>>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 >>>>=20 >>>> Now, the questions that seems to be hanging around are >>>>=20 >>>> 1) Aren't these two mechanisms solving pretty much the same problem? >>>> 2) Do we need to have two standards for the same functionality? >>>> 3) Do you guys have a position or comments regarding either one of th= em? >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> PS: Please also let me know if your view is: "I don't really know what= all this is about and the documents actually don't provide enough requirem= ents to make a reasonable judgement about the solution space." >>>>=20 >>>=20 >>> So just as a data-point. We (the IETF, but including >>> me personally;-) mucked up badly on this some years >>> ago in the PKI space - we standardised both CMP (rfc >>> 2510) and CMC (rfc 2797) as two ways to do the same >>> thing, after a protracted battle between factions >>> supporting one or the other. We even made sure they >>> had as much common syntax as possible. (CRMF, rfc >>> 2511) >>>=20 >>> Result: neither fully adopted, lots of people still >>> do proprietary stuff, neither can be killed off >>> (despite attempts), both need to be maintained (CMP >>> is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO >>> partly as a result of us screwing up for what seemed >>> like good reasons at the time, PKI administration >>> stuff has never gotten beyond horrible-to-do. >>>=20 >>> All-in-all, a really bad outcome which is still >>> a PITA a dozen years later. >>>=20 >>> As OAuth AD I will need *serious* convincing that >>> there is a need to provide two ways to do the same >>> thing. I doubt it'll be possible to convince me, >>> in fact, so if you wanna try, you'll need to start >>> by saying that they are not in fact two ways to do >>> the same thing:-) >>>=20 >>> S. >>>=20 >>> PS: This discussion needs to also involve the Apps >>> area, so I've cc'd that list. >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Thu Apr 12 11:29:19 2012 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 AC9DC21F85D0 for ; Thu, 12 Apr 2012 11:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KamVJi8kP2sg for ; Thu, 12 Apr 2012 11:29:18 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDB621F85A2 for ; Thu, 12 Apr 2012 11:29:18 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q3CITHJS009668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Apr 2012 13:29:17 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3CITGht014548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Apr 2012 13:29:16 -0500 Received: from [135.222.232.147] (USMUYN0L055118.mh.lucent.com [135.222.232.147]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3CITFER017406; Thu, 12 Apr 2012 13:29:16 -0500 (CDT) Message-ID: <4F871EFB.6000807@alcatel-lucent.com> Date: Thu, 12 Apr 2012 14:29:15 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: John Bradley References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F86C437.3000006@cs.tcd.ie> <4F871201.1000103@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:29:19 -0000 John, I agree with you on everything you said about the differences. My question: Are these not about API rather than the protocol? (I was just trying to see if I can find a common fixed point to start with.) Igor On 4/12/2012 2:00 PM, John Bradley wrote: > There are important deployment and privacy issues that caused openID Connect to use SWD. > > I was part of the OASIS XRI/XRD work that Web Finger has been based on. > > The main differences are around allowing all of the users information to be publicly discoverable, vs providing for access control. > > They are similar, but have real design differences. > > Web Finger without XML is not horrible by any means, but nether is SWD. > > SWD is more about users while host-meta is more about server resources. > > John B. > > > On 2012-04-12, at 7:33 PM, Igor Faynberg wrote: > >> To me this looks like more than the same problem being solved--it appears to be the same protocol... I wonder if, the representation issues were put aside (i.e., left to the API specification), the common part is what can be adopted. >> >> Igor >> >> On 4/12/2012 8:01 AM, Stephen Farrell wrote: >>> >>> On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: >>>> Hi all, >>>> >>>> those who had attended the last IETF meeting may have noticed the ongoing activity in the 'Applications Area Working Group' regarding Web Finger. >>>> We had our discussion regarding Simple Web Discovery (SWD) as part of the re-chartering process. >>>> >>>> Here are the two specifications: >>>> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 >>>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 >>>> >>>> Now, the questions that seems to be hanging around are >>>> >>>> 1) Aren't these two mechanisms solving pretty much the same problem? >>>> 2) Do we need to have two standards for the same functionality? >>>> 3) Do you guys have a position or comments regarding either one of them? >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: Please also let me know if your view is: "I don't really know what all this is about and the documents actually don't provide enough requirements to make a reasonable judgement about the solution space." >>>> >>> So just as a data-point. We (the IETF, but including >>> me personally;-) mucked up badly on this some years >>> ago in the PKI space - we standardised both CMP (rfc >>> 2510) and CMC (rfc 2797) as two ways to do the same >>> thing, after a protracted battle between factions >>> supporting one or the other. We even made sure they >>> had as much common syntax as possible. (CRMF, rfc >>> 2511) >>> >>> Result: neither fully adopted, lots of people still >>> do proprietary stuff, neither can be killed off >>> (despite attempts), both need to be maintained (CMP >>> is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO >>> partly as a result of us screwing up for what seemed >>> like good reasons at the time, PKI administration >>> stuff has never gotten beyond horrible-to-do. >>> >>> All-in-all, a really bad outcome which is still >>> a PITA a dozen years later. >>> >>> As OAuth AD I will need *serious* convincing that >>> there is a need to provide two ways to do the same >>> thing. I doubt it'll be possible to convince me, >>> in fact, so if you wanna try, you'll need to start >>> by saying that they are not in fact two ways to do >>> the same thing:-) >>> >>> S. >>> >>> PS: This discussion needs to also involve the Apps >>> area, so I've cc'd that list. >>> >>>> >>>> >>>> _______________________________________________ >>>> 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 From ve7jtb@ve7jtb.com Thu Apr 12 11:31:29 2012 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 A11D021F8625 for ; Thu, 12 Apr 2012 11:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDyzQiuZ8DEg for ; Thu, 12 Apr 2012 11:31:28 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 783E321F860B for ; Thu, 12 Apr 2012 11:31:28 -0700 (PDT) Received: by eeke51 with SMTP id e51so621186eek.31 for ; Thu, 12 Apr 2012 11:31:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=eum2+dM7V5NLLCj69VErw4gEfOzOPu+t6HrkUrAHBAw=; b=laaM/9FC7O/BGD/rCv8ESmSabF2P9l1Sx4Pn+4ImUKUNwsMt90N1clK9KnO+V8sLsM gtxxlkgsfBbCSVF+j8LeHgmLE5QzZJ55t3vvlqxxwEr8i/VgowNud6g5UyMAhaybEyCT N6GsiLTP/lUqMMN3la9k9DRQIR58d1AvJFI/gMS4tVAXRrBB2PPuDryNTb1Cph5Op2xh lXpuY1+CadW+r8QugzkGvbpzkblCdzkCqraOW6usfO2/VYVuJIjsu7EhlDRSbBpJe/da bx07nnHQ0xuW47CohRXTY3resCNeRMwheKZJXdKVZQBxwyHT1dQ05gF6unCyqhQSTGBA fgdg== Received: by 10.14.99.6 with SMTP id w6mr536020eef.68.1334255487354; Thu, 12 Apr 2012 11:31:27 -0700 (PDT) Received: from [10.0.10.185] ([212.144.56.68]) by mx.google.com with ESMTPS id n55sm31344058eef.6.2012.04.12.11.31.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 11:31:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_C987BFFD-8854-46AD-8B4B-1DF1A3E326D9"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Thu, 12 Apr 2012 20:31:23 +0200 Message-Id: <52663308-D1B3-47B1-8F8B-5BF1E8EE9EC7@ve7jtb.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F86C437.3000006@cs.tcd.ie> <4F871201.1000103@alcatel-lucent.com>, To: Eran Hammer X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQm2ylQsWbNIFnVnLI6Ee4sl4fo7ZmOyU1t3C4M1MBWAQM7kjWsAPxdjAC50+D++IIZaEOrX Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 12 Apr 2012 18:31:29 -0000 --Apple-Mail=_C987BFFD-8854-46AD-8B4B-1DF1A3E326D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii SWD takes more of a API approach where a query is made about a specific = resource type about a specific subject (email format or URI ). The current draft of the spec doesn't go into detail on how a requester = is identified and given authorization to discover the resource. One = could imagine that being done with OAuth.=20 You could do a similar thing with web finger, however given that the = typical deployment is more of a document model, that is harder for some = large sites to deploy.=20 Is everything in SWD fully sorted out, well no otherwise it would not be = bing brought to the IETF for standardization. As we discussed in Paris many of the goals are similar but there are = implementation differences.=20 I could also say that the Web Finger approach is more user-centric for = sites where users have direct control over editing there own pages. =20= In most cases, that is not the reality however.=20 John B. On 2012-04-12, at 8:18 PM, Eran Hammer wrote: > Where is this access control and user centric architecture described? = I could not find it.=20 >=20 > EH >=20 > On Apr 12, 2012, at 14:01, "John Bradley" wrote: >=20 >> There are important deployment and privacy issues that caused openID = Connect to use SWD. >>=20 >> I was part of the OASIS XRI/XRD work that Web Finger has been based = on. >>=20 >> The main differences are around allowing all of the users information = to be publicly discoverable, vs providing for access control.=20 >>=20 >> They are similar, but have real design differences. >>=20 >> Web Finger without XML is not horrible by any means, but nether is = SWD. >>=20 >> SWD is more about users while host-meta is more about server = resources. >>=20 >> John B. >>=20 >>=20 >> On 2012-04-12, at 7:33 PM, Igor Faynberg wrote: >>=20 >>> To me this looks like more than the same problem being solved--it = appears to be the same protocol... I wonder if, the representation = issues were put aside (i.e., left to the API specification), the common = part is what can be adopted. >>>=20 >>> Igor >>>=20 >>> On 4/12/2012 8:01 AM, Stephen Farrell wrote: >>>>=20 >>>>=20 >>>> On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: >>>>> Hi all, >>>>>=20 >>>>> those who had attended the last IETF meeting may have noticed the = ongoing activity in the 'Applications Area Working Group' regarding Web = Finger. >>>>> We had our discussion regarding Simple Web Discovery (SWD) as part = of the re-chartering process. >>>>>=20 >>>>> Here are the two specifications: >>>>> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 >>>>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 >>>>>=20 >>>>> Now, the questions that seems to be hanging around are >>>>>=20 >>>>> 1) Aren't these two mechanisms solving pretty much the same = problem? >>>>> 2) Do we need to have two standards for the same functionality? >>>>> 3) Do you guys have a position or comments regarding either one of = them? >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>> PS: Please also let me know if your view is: "I don't really know = what all this is about and the documents actually don't provide enough = requirements to make a reasonable judgement about the solution space." >>>>>=20 >>>>=20 >>>> So just as a data-point. We (the IETF, but including >>>> me personally;-) mucked up badly on this some years >>>> ago in the PKI space - we standardised both CMP (rfc >>>> 2510) and CMC (rfc 2797) as two ways to do the same >>>> thing, after a protracted battle between factions >>>> supporting one or the other. We even made sure they >>>> had as much common syntax as possible. (CRMF, rfc >>>> 2511) >>>>=20 >>>> Result: neither fully adopted, lots of people still >>>> do proprietary stuff, neither can be killed off >>>> (despite attempts), both need to be maintained (CMP >>>> is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO >>>> partly as a result of us screwing up for what seemed >>>> like good reasons at the time, PKI administration >>>> stuff has never gotten beyond horrible-to-do. >>>>=20 >>>> All-in-all, a really bad outcome which is still >>>> a PITA a dozen years later. >>>>=20 >>>> As OAuth AD I will need *serious* convincing that >>>> there is a need to provide two ways to do the same >>>> thing. I doubt it'll be possible to convince me, >>>> in fact, so if you wanna try, you'll need to start >>>> by saying that they are not in fact two ways to do >>>> the same thing:-) >>>>=20 >>>> S. >>>>=20 >>>> PS: This discussion needs to also involve the Apps >>>> area, so I've cc'd that list. >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>> _______________________________________________ >>>> 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 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C987BFFD-8854-46AD-8B4B-1DF1A3E326D9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx MjE4MzEyNFowIwYJKoZIhvcNAQkEMRYEFL/cZ2FWfq0unwPu0a7sOOvfmpP9MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACzu3xSJ+5ARQGRL14oWHb9FDmgtl5iDPXkdzekt0zO+N8YL4f6lPYzZFcChTXe847pwM/TbJVjK 8PW9/4Mq8YPMBcomCJVcApQ0pnizWgSSiRHjJ5F/L7wOvjsoucfaPthpRJmwLor6XsGOyqYXJ2Fg XJKYLLatdlR7Hmy9Vkt3RcVCeOQxTSxS9npSViGRi5/n5p8I41WFcdP7ZDY23fxizWaN1ixv3Y9P l3EuGoc+RoQzNfI4XwS+faHh5WMoWFzPzYVKOaceniGiFdGCglslla5g9wFDEXQZcIMKllBAfEr+ ol32nVYSPYkK39Bz/56OPEPqaQ2Jc3k9z/mWiGYAAAAAAAA= --Apple-Mail=_C987BFFD-8854-46AD-8B4B-1DF1A3E326D9-- From Adam.Lewis@motorolasolutions.com Thu Apr 12 12:01:40 2012 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 C273521F8623 for ; Thu, 12 Apr 2012 12:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2poJQyWpt1K for ; Thu, 12 Apr 2012 12:01:40 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6C821F863F for ; Thu, 12 Apr 2012 12:01:38 -0700 (PDT) Received: from mail110-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 19:01:37 +0000 Received: from mail110-am1 (localhost [127.0.0.1]) by mail110-am1-R.bigfish.com (Postfix) with ESMTP id C520A220516 for ; Thu, 12 Apr 2012 19:01:37 +0000 (UTC) X-SpamScore: -1 X-BigFish: PS-1(zzc85fh14ffIzz1202hzz8275bh8275dhz2fh2a8h683h839hd25h) X-Forefront-Antispam-Report: CIP:192.160.210.14; KIP:(null); UIP:(null); IPV:NLI; H:il27msg02.am.mot-solutions.com; RD:il27msg02.mot-solutions.com; EFVD:NLI Received-SPF: pass (mail110-am1: domain of motorolasolutions.com designates 192.160.210.14 as permitted sender) client-ip=192.160.210.14; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il27msg02.am.mot-solutions.com ; olutions.com ; Received: from mail110-am1 (localhost.localdomain [127.0.0.1]) by mail110-am1 (MessageSwitch) id 1334257295760610_28500; Thu, 12 Apr 2012 19:01:35 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.242]) by mail110-am1.bigfish.com (Postfix) with ESMTP id ABE3A30004E for ; Thu, 12 Apr 2012 19:01:35 +0000 (UTC) Received: from il27msg02.am.mot-solutions.com (192.160.210.14) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 19:01:33 +0000 Received: from il27msg02.am.mot-solutions.com (ct11vts01.am.mot.com [10.177.16.159]) by il27msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3CJ4Bw7028539 for ; Thu, 12 Apr 2012 15:04:11 -0400 (EDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by il27msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3CJ49Zt028536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 Apr 2012 15:04:10 -0400 (EDT) Received: from mail89-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 19:01:29 +0000 Received: from mail89-am1 (localhost [127.0.0.1]) by mail89-am1-R.bigfish.com (Postfix) with ESMTP id 11060C058C for ; Thu, 12 Apr 2012 19:01:29 +0000 (UTC) Received: from mail89-am1 (localhost.localdomain [127.0.0.1]) by mail89-am1 (MessageSwitch) id 1334257286900172_10519; Thu, 12 Apr 2012 19:01:26 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.233]) by mail89-am1.bigfish.com (Postfix) with ESMTP id D7248340263 for ; Thu, 12 Apr 2012 19:01:26 +0000 (UTC) Received: from CH1PRD0410HT001.namprd04.prod.outlook.com (157.56.244.181) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 19:01:25 +0000 Received: from CH1PRD0410MB369.namprd04.prod.outlook.com ([169.254.6.77]) by CH1PRD0410HT001.namprd04.prod.outlook.com ([10.255.147.36]) with mapi id 14.16.0143.004; Thu, 12 Apr 2012 19:01:23 +0000 From: Lewis Adam-CAL022 To: "oauth@ietf.org" Thread-Topic: Using OAuth to get a JWT/SAML token Thread-Index: Ac0Y3qYjDhOGJvrlS5yWtkyY/5uu1g== Date: Thu, 12 Apr 2012 19:01:22 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A906E74E@CH1PRD0410MB369.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.36.211] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A906E74ECH1PRD0410MB369na_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0410HT001.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False;00160000;True;; X-OrganizationHeadersPreserved: CH1PRD0410HT001.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Subject: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Thu, 12 Apr 2012 19:01:40 -0000 --_000_59E470B10C4630419ED717AC79FCF9A906E74ECH1PRD0410MB369na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've been talking to some of you off line about this already, but I need so= me help in terms of implementation. I would like to use OAuth as a means t= o get either a JWT or SAML token to a client running on a handheld device. = This is something that I'm looking to prototype (as part of a larger proje= ct) beginning this week. So, it is important to me to understand the divid= e between what is theoretically possible and what is actually possible. Anybody aware of any implementations out there, either vendor or open sourc= e, that I can use for this? Tx! adam --_000_59E470B10C4630419ED717AC79FCF9A906E74ECH1PRD0410MB369na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,<= /span>

 

I’ve been tal= king to some of you off line about this already, but I need some help in te= rms of implementation.  I would like to use OAuth as a means to get ei= ther a JWT or SAML token to a client running on a handheld device.  This is something that I’m looking to proto= type (as part of a larger project) beginning this week.  So, it is imp= ortant to me to understand the divide between what is theoretically possibl= e and what is actually possible.

 

Anybody aware of an= y implementations out there, either vendor or open source, that I can use f= or this?

 

Tx!
adam

--_000_59E470B10C4630419ED717AC79FCF9A906E74ECH1PRD0410MB369na_-- From ve7jtb@ve7jtb.com Thu Apr 12 12:57:11 2012 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 005A421F85F8 for ; Thu, 12 Apr 2012 12:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-L9v8ydRL0c for ; Thu, 12 Apr 2012 12:57:10 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4E6921F85F4 for ; Thu, 12 Apr 2012 12:57:09 -0700 (PDT) Received: by werb10 with SMTP id b10so1815883wer.31 for ; Thu, 12 Apr 2012 12:57:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Y/fgxJ01R+xzj/O/kqtlxjXgeYZYtpGjX93MApaAC2w=; b=YW4XEAeYu85DKPDvz6MDOP5LU377mtVF/s3KLtjP8TFEoluql1ZkPZHmUW35IYYKf5 0R4Ykd1aYu/eol+ZBjZaoUwsRG4aqba082Olb6kWsR7Sni4mx+nscoFJQi4XWAG/W5V8 4iYglDe/RHJ7JfFyQRCY5Pi9f2DkFogqkT07k3z1+VERVl2wuobAgOGQLJfo5T/r88GX HEuQxNJEdfgc6YigaJCjXnsslEkBHYl0p925xqJFlIi5NjIZqNo6owBIT7USZVZVWrdc gvOV3qnXgbAIpaAUPOxwqnFEhDjzVzR1dxVZF/z9yoT3+Sn3rB/kQuyVqJBnxvdFMPpo BpDA== Received: by 10.180.101.136 with SMTP id fg8mr7381707wib.4.1334260628789; Thu, 12 Apr 2012 12:57:08 -0700 (PDT) Received: from [10.0.10.185] ([212.144.56.68]) by mx.google.com with ESMTPS id k6sm54525404wie.9.2012.04.12.12.57.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 12:57:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_6BB0FDBD-2285-4846-8073-FCC4486F72E4"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4F871EFB.6000807@alcatel-lucent.com> Date: Thu, 12 Apr 2012 21:56:59 +0200 Message-Id: <291BA738-06A8-4993-A251-DD148B89F1A3@ve7jtb.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F86C437.3000006@cs.tcd.ie> <4F871201.1000103@alcatel-lucent.com> <4F871EFB.6000807@alcatel-lucent.com> To: igor.faynberg@alcatel-lucent.com X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQk4X7aP0FSPcdDGIfO7yfFGdb/KaTQq7sXhZxpoBif8YSr33bnj6EiW8x5OMB8K4p99jZS3 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 12 Apr 2012 19:57:11 -0000 --Apple-Mail=_6BB0FDBD-2285-4846-8073-FCC4486F72E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 There is no reason that SWD would not be a host service that host-meta = could list like any other. That should be supported now by the host-meta spec. =20 The question is client complexity. =20 A client could look in host-meta and do SWD if it finds that service and = no mapping template, or the other way around. =20 The question is do we want to add the complexity to clients where they = have to support multiple discovery specs. I seem to recall people calling me the devil for XRI resolution in = openID 2.0. Not to offend but Web Finger is XRI resolution without the central = registry. John B. On 2012-04-12, at 8:29 PM, Igor Faynberg wrote: > John, >=20 > I agree with you on everything you said about the differences. My = question: Are these not about API rather than the protocol? >=20 > (I was just trying to see if I can find a common fixed point to start = with.) >=20 > Igor >=20 > On 4/12/2012 2:00 PM, John Bradley wrote: >> There are important deployment and privacy issues that caused openID = Connect to use SWD. >>=20 >> I was part of the OASIS XRI/XRD work that Web Finger has been based = on. >>=20 >> The main differences are around allowing all of the users information = to be publicly discoverable, vs providing for access control. >>=20 >> They are similar, but have real design differences. >>=20 >> Web Finger without XML is not horrible by any means, but nether is = SWD. >>=20 >> SWD is more about users while host-meta is more about server = resources. >>=20 >> John B. >>=20 >>=20 >> On 2012-04-12, at 7:33 PM, Igor Faynberg wrote: >>=20 >>> To me this looks like more than the same problem being solved--it = appears to be the same protocol... I wonder if, the representation = issues were put aside (i.e., left to the API specification), the common = part is what can be adopted. >>>=20 >>> Igor >>>=20 >>> On 4/12/2012 8:01 AM, Stephen Farrell wrote: >>>>=20 >>>> On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: >>>>> Hi all, >>>>>=20 >>>>> those who had attended the last IETF meeting may have noticed the = ongoing activity in the 'Applications Area Working Group' regarding Web = Finger. >>>>> We had our discussion regarding Simple Web Discovery (SWD) as part = of the re-chartering process. >>>>>=20 >>>>> Here are the two specifications: >>>>> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 >>>>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 >>>>>=20 >>>>> Now, the questions that seems to be hanging around are >>>>>=20 >>>>> 1) Aren't these two mechanisms solving pretty much the same = problem? >>>>> 2) Do we need to have two standards for the same functionality? >>>>> 3) Do you guys have a position or comments regarding either one = of them? >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>> PS: Please also let me know if your view is: "I don't really know = what all this is about and the documents actually don't provide enough = requirements to make a reasonable judgement about the solution space." >>>>>=20 >>>> So just as a data-point. We (the IETF, but including >>>> me personally;-) mucked up badly on this some years >>>> ago in the PKI space - we standardised both CMP (rfc >>>> 2510) and CMC (rfc 2797) as two ways to do the same >>>> thing, after a protracted battle between factions >>>> supporting one or the other. We even made sure they >>>> had as much common syntax as possible. (CRMF, rfc >>>> 2511) >>>>=20 >>>> Result: neither fully adopted, lots of people still >>>> do proprietary stuff, neither can be killed off >>>> (despite attempts), both need to be maintained (CMP >>>> is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO >>>> partly as a result of us screwing up for what seemed >>>> like good reasons at the time, PKI administration >>>> stuff has never gotten beyond horrible-to-do. >>>>=20 >>>> All-in-all, a really bad outcome which is still >>>> a PITA a dozen years later. >>>>=20 >>>> As OAuth AD I will need *serious* convincing that >>>> there is a need to provide two ways to do the same >>>> thing. I doubt it'll be possible to convince me, >>>> in fact, so if you wanna try, you'll need to start >>>> by saying that they are not in fact two ways to do >>>> the same thing:-) >>>>=20 >>>> S. >>>>=20 >>>> PS: This discussion needs to also involve the Apps >>>> area, so I've cc'd that list. >>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>> _______________________________________________ >>>> 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 --Apple-Mail=_6BB0FDBD-2285-4846-8073-FCC4486F72E4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx MjE5NTY2MFowIwYJKoZIhvcNAQkEMRYEFP7o13iSkxvIfMukvAY+BqDEnp+7MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AJ56M84gPyBpKwtUYrWBlVM4Mctmjp6cMd6OZqJ14mfG+syS1tCwRWlj50kBJkOjvDyWBD+h1DPZ cXdt3UJkZ5/hFNK8uOi7Cz/pLbWHU5WYuGama+EWGsm6ZQseBk8vF+ztFa4aKsKoIGXeBKP6FVVT x2Pt96sYiYma3TrB8Eyg1YcWTSWWEEm6hBIOB2Rx+a7IO+b+TuYjkqmc+0hUnLxBTUo9jj1DMWKZ LGaDswyQ7fn0yqvdrEbDHb5xDjppICq4NYbNtTEg1i/Y5zV9DGYgP35GSV+ncLynT0BFZerORRbG nno20CdD9LJCvPWDCD5z+OUJ8hdAMiylE8fF2iEAAAAAAAA= --Apple-Mail=_6BB0FDBD-2285-4846-8073-FCC4486F72E4-- From Michael.Jones@microsoft.com Thu Apr 12 14:22:13 2012 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 863DC21F853D for ; Thu, 12 Apr 2012 14:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhlWTCXfTEDh for ; Thu, 12 Apr 2012 14:22:12 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0621F853B for ; Thu, 12 Apr 2012 14:22:11 -0700 (PDT) Received: from mail38-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 21:22:10 +0000 Received: from mail38-am1 (localhost [127.0.0.1]) by mail38-am1-R.bigfish.com (Postfix) with ESMTP id 33EBB4E05C5 for ; Thu, 12 Apr 2012 21:22:10 +0000 (UTC) X-SpamScore: -43 X-BigFish: VS-43(z6caMzbb2dI9371I542M1432N98dK11fbI199bIzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail38-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail38-am1 (localhost.localdomain [127.0.0.1]) by mail38-am1 (MessageSwitch) id 1334265723636403_1215; Thu, 12 Apr 2012 21:22:03 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.228]) by mail38-am1.bigfish.com (Postfix) with ESMTP id F29B61C0103 for ; Thu, 12 Apr 2012 21:22:01 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 21:22:00 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0283.004; Thu, 12 Apr 2012 21:21:57 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Updated Charter to the IESG (this weekend) Thread-Index: AQHNGJrBAuQglVZ/R0WeZTzlbF/CnpaXaZEAgABJplA= Date: Thu, 12 Apr 2012 21:21:56 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664657B6@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F87098C.7070408@alcatel-lucent.com> In-Reply-To: <4F87098C.7070408@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Thu, 12 Apr 2012 21:22:13 -0000 I agree that this looks good. My only suggestion is that we move up the pr= oposed submission dates for JWT and JWT Profile from March 2013 to November= 2012, since the JOSE specs that JWT is largely based upon are scheduled fo= r submission in July, per http://datatracker.ietf.org/wg/jose/charter/. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of I= gor Faynberg Sent: Thursday, April 12, 2012 9:58 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) Hannes, I took a look (a bit longer than just "quick"), and what I see completely c= oincides with my understanding of the result of the discussions. Good job! Igor On 4/12/2012 6:55 AM, Hannes Tschofenig wrote: > Hey guys > > based on the discussion before, during, and after the Paris IETF meeting = I am going to send the following updated charter / milestones to the IESG. > Please have a quick look (till the end of the week) to double-check the c= ontent (particularly the suggested milestone dates): > > ---------- > > > Web Authorization Protocol (oauth) > > Description of Working Group > > The Web Authorization (OAuth) protocol allows a user to grant a=20 > third-party Web site or application access to the user's protected=20 > resources, without necessarily revealing their long-term credentials,=20 > or even their identity. For example, a photo-sharing site that=20 > supports OAuth could allow its users to use a third-party printing Web=20 > site to print their private pictures, without allowing the printing=20 > site to gain full control of the user's account and without having the=20 > user sharing his or her photo-sharing sites' long-term credential with=20 > the printing site. > > The OAuth protocol suite encompasses > * a procedure for allowing a client to discover a resource server, > * a protocol for obtaining authorization tokens from an authorization=20 > server with the resource owner's consent, > * protocols for presenting these authorization tokens to protected=20 > resources for access to a resource, and > * consequently for sharing data in a security and privacy respective way. > > In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,=20 > was published as an informational document (RFC 5849). With the=20 > completion of OAuth 1.0 the working group started their work on OAuth=20 > 2.0 to incorporate implementation experience with version 1.0,=20 > additional use cases, and various other security, readability, and=20 > interoperability improvements. An extensive security analysis was=20 > conducted and the result is available as a stand-alone document=20 > offering guidance for audiences beyond the community of protocol implemen= ters. > > The working group also developed security schemes for presenting=20 > authorization tokens to access a protected resource. This led to the=20 > publication of the bearer token as well as the message authentication=20 > code (MAC) access authentication specification. > > OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH=20 > token with the SAML 2.0 bearer assertion profile. This offers=20 > interworking with existing identity management solutions, in particular S= AML based deployments. > > OAuth has enjoyed widespread adoption by the Internet application=20 > service provider community. To build on this success we aim for=20 > nothing more than to make OAuth the authorization framework of choice=20 > for any Internet protocol. Consequently, the ongoing standardization=20 > effort within the OAuth working group is focused on enhancing=20 > interoperability of OAuth deployments. While the core OAuth=20 > specification truly is an important building block it relies on other=20 > specifications in order to claim completeness. Luckily, these=20 > components already exist and have been deployed on the Internet. Through = the IETF standards process they will be improved in quality and will underg= o a rigorous review process. > > Goals and Milestones > > [Editor's Note: Here are the completed items.] > > Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a=20 > working group item Done Submit 'HTTP Authentication: MAC=20 > Authentication' as a working group item Done Submit 'The OAuth 2.0=20 > Protocol: Bearer Tokens' to the IESG for consideration as a Proposed=20 > Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the=20 > IESG for consideration as a Proposed Standard > > [Editor's Note: Finishing existing work. Double-check the proposed=20 > dates - are they realistic?] > > May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0'=20 > to the IESG for consideration as a Proposed Standard May 2012 Submit=20 > 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a=20 > Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace for=20 > OAuth' to the IESG for consideration as a Proposed Standard May 2012 =20 > Submit 'OAuth 2.0 Threat Model and Security Considerations' to the=20 > IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP=20 > Authentication: MAC Authentication' to the IESG for consideration as a=20 > Proposed Standard > > [Editor's Note: New work for the group] > > Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as=20 > a Proposed Standard > > [Starting point for the work will be=20 > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] > > Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as=20 > an Informational RFC > > [Starting point for the work will be=20 > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] > > Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration=20 > as a Proposed Standard > > [Starting point for the work will be=20 > http://tools.ietf.org/html/draft-jones-simple-web-discovery] > > Mar. 2013 Submit 'JSON Web Token (JWT)' to the IESG for consideration=20 > as a Proposed Standard > > [Starting point for the work will be=20 > http://tools.ietf.org/html/draft-jones-json-web-token] > > Mar. 2013 Submit 'JSON Web Token (JWT) Bearer Token Profiles for=20 > OAuth 2.0' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be=20 > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] > > Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the=20 > IESG for consideration as a Proposed Standard > > [Starting point for the work will be=20 > http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] > > > _______________________________________________ > 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 From bcampbell@pingidentity.com Thu Apr 12 14:29:55 2012 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 DFFE621F8786 for ; Thu, 12 Apr 2012 14:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.947 X-Spam-Level: X-Spam-Status: No, score=-5.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZl8J8ZrEBla for ; Thu, 12 Apr 2012 14:29:55 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id 32EF321F8771 for ; Thu, 12 Apr 2012 14:29:55 -0700 (PDT) Received: from mail-vx0-f172.google.com ([209.85.220.172]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKT4dJUp5rDR4oJLO0VW2eeAWjdcPKPo37@postini.com; Thu, 12 Apr 2012 14:29:55 PDT Received: by vcbfk13 with SMTP id fk13so1713217vcb.3 for ; Thu, 12 Apr 2012 14:29:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=TTx5c7/7bGzyEItEku8395QYs3hZmWKv6XwJWrUkx44=; b=SyU8aGI/hLvhJAeQhSfoVGi/hpUaB2pKo/wVsuEjA40+46c0Pwa1vDyQhQlpPiQk8l Cbq3gvFOCKap7KbVw4h8q5FiCE5rAVsA1aXCVL0GD/89dM+BUnAtaihRsk/qNSOleon4 DKQ/s6WTsQX/ps9T9aCfOKeG7x14KxmOfcQhvBQvrSJfXJtO+qJvg0aYXLTO5J4+vzv4 EqkuvYP32NFq4eqpgnGmf6ZcJDRcPGyueD0cRlWaX+aIfvX7X8XAyUh6Up6APNwupFfi vDMUPTPHqMotX3MVf97CRD5tz5aJuuosTu2e8n6asHBrC3biI0JAOIsg0IjcNMGQMSZy Ef8Q== Received: by 10.52.65.170 with SMTP id y10mr1667936vds.48.1334266193694; Thu, 12 Apr 2012 14:29:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.38.104 with HTTP; Thu, 12 Apr 2012 14:29:23 -0700 (PDT) From: Brian Campbell Date: Thu, 12 Apr 2012 15:29:23 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnLDIupA7emKXqhk5syyLtu5G1f9c0li167d9h0WTzHPrCJmbtYRC6pwTPKEtIlmJEOAzO3 Subject: [OAUTH-WG] typo/missing word in JWT and SAML I-Ds 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: Thu, 12 Apr 2012 21:29:56 -0000 I was putting together a little summary writeup on some of these drafts yesterday and I noticed a missing "a" in the abstract of http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03 - it says, "This specification defines the use of a JSON Web Token (JWT) Bearer Token as means for requesting..." but should probably say "This specification defines the use of a JSON Web Token (JWT) Bearer Token as *a* means for requesting..." And http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10 has nearly the identical omission. The latter draft is in WGLC and I wasn't sure if I should produce a new revision to correct this little editorial item now or wait until after last call? From Michael.Jones@microsoft.com Thu Apr 12 14:51:33 2012 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 877AF21F8710 for ; Thu, 12 Apr 2012 14:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.922 X-Spam-Level: X-Spam-Status: No, score=-3.922 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUzRb-flcc61 for ; Thu, 12 Apr 2012 14:51:32 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id D1A7E21F8723 for ; Thu, 12 Apr 2012 14:51:31 -0700 (PDT) Received: from mail18-db3-R.bigfish.com (10.3.81.231) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 12 Apr 2012 21:51:31 +0000 Received: from mail18-db3 (localhost [127.0.0.1]) by mail18-db3-R.bigfish.com (Postfix) with ESMTP id BE99742093E; Thu, 12 Apr 2012 21:51:30 +0000 (UTC) X-SpamScore: -34 X-BigFish: VS-34(zz9371I14ffI168aJ542M148cMzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail18-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail18-db3 (localhost.localdomain [127.0.0.1]) by mail18-db3 (MessageSwitch) id 1334267489164004_16208; Thu, 12 Apr 2012 21:51:29 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.251]) by mail18-db3.bigfish.com (Postfix) with ESMTP id 17D464C00EC; Thu, 12 Apr 2012 21:51:29 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 12 Apr 2012 21:51:27 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0283.004; Thu, 12 Apr 2012 21:51:22 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNGJt50G7JnMt5ukqcfN3YYKxyCZaXuy7g Date: Thu, 12 Apr 2012 21:51:22 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366465919@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> In-Reply-To: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 12 Apr 2012 21:51:33 -0000 Thanks for asking these questions Hannes. I'll first provide a brief featu= re comparison of Simple Web Discovery and WebFinger and then answer your qu= estions. FEATURE COMPARISON RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: SWD returns the resource l= ocation(s) for a specific resource for a specific principal. WebFinger ret= urns all resources for the principal. The example at http://tools.ietf.org= /html/draft-jones-appsawg-webfinger-03#section-3.2 "Retrieving a Person's C= ontact Information" is telling. The WebFinger usage model seems to be "I'l= l get everything about you and then fish through it to decide what to do wi= th it." The protocol assumption that all WebFinger information must be pub= lic is also built into the protocol where the CORS response header "Access-= Control-Allow-Origin: *" is mandated, per http://tools.ietf.org/html/draft-= jones-appsawg-webfinger-03#section-7. The privacy characteristics of these= approaches are very different. (It's these very same privacy characterist= ics that led sysadmins to nearly ubiquitously disabling the fingerd service= !) Particularly for the OAuth use cases, narrow, scoped, and potentially p= ermissioned responses seem preferable. DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURITY: WebFinger is built= on a "document model", where a single document is returned that contains m= ultiple resources for a principal. SWD is built on an "API model", where t= he location(s) of a particular resource for a principal are returned. The = problem with the document model is that different parties or services may b= e authoritative for different resources for a given principal, and yet all = need the rights to edit the resulting document. This hurts deployability, = because document edits then need to be coordinated among parties that may h= ave different rights and responsibilities, and may have negative security i= mplications as well. (Just because I can change your avatar doesn't mean t= hat I should be able to change your mail server.) REDIRECT FUNCTIONALITY AND DEPLOYABILTY: SWD includes the ability to redir= ect some or all SWD requests to another location (possibly depending upon t= he specific resource and principal parameters). Deployers hosting numerous= sites for others told the SWD authors that this functionality is critical = for deployability, as it means that the SWD server for a domain can live in= a location outside the domain. WebFinger is lacking this functionality. = Given that OAuth is likely to be used in hosted environments, this function= ality seems pretty important. NUMBER OF ROUND TRIPS: WebFinger discoveries for user information normally= require both a host-meta query to retrieve the template and then a second = query to retrieve the user's information. This functionality is achieved i= n a single SWD query. XML AND JSON VERSUS JSON: WebFinger specifies both XML and JSON support, w= hereas SWD specifies only JSON. The SWD position is that it's simpler to s= pecify only one way of doing the same thing, with JSON being chosen because= it's simpler for developers to use than XML - the same decision as made fo= r the OAuth specs. DEFINING SPECIFIC RESOURCES: Besides specifying a discovery protocol, WebF= inger also defines specific resources and kinds of resources to be used wit= h that protocol: the "acct" URI scheme, the "acct" Link Relation. These s= hould be considered on their own merits, but logically should be decoupled = from the discovery protocol into a different document or documents. It's n= ot clear these features would be needed in OAuth contexts. QUESTIONS 1) Aren't these two mechanisms solving pretty much the same problem? They are solving an overlapping set of problems, but with ve= ry different privacy characteristics, different deployability characteristi= cs, different security characteristics, and somewhat different mechanisms. 2) Do we need to have two standards for the same functionality? No - Simple Web Discovery is sufficient for the OAuth use ca= ses (and likely for others as well). 3) Do you guys have a position or comments regarding either one of them? The functionality in Simple Web Discovery is minimal and suf= ficient for the OAuth use cases, whereas some of the functionality and assu= mptions made in WebFinger are harmful, both from a privacy and from a deplo= yability perspective. SWD should proceed to standardization; WebFinger sho= uld not. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Thursday, April 12, 2012 4:00 AM To: oauth@ietf.org WG Subject: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Hi all,=20 those who had attended the last IETF meeting may have noticed the ongoing a= ctivity in the 'Applications Area Working Group' regarding Web Finger.=20 We had our discussion regarding Simple Web Discovery (SWD) as part of the r= e-chartering process.=20 Here are the two specifications: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 Now, the questions that seems to be hanging around are 1) Aren't these two mechanisms solving pretty much the same problem? 2) Do we need to have two standards for the same functionality? 3) Do you guys have a position or comments regarding either one of them?=20 Ciao Hannes PS: Please also let me know if your view is: "I don't really know what all = this is about and the documents actually don't provide enough requirements = to make a reasonable judgement about the solution space." _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Thu Apr 12 15:14:53 2012 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 BD0A921F8755 for ; Thu, 12 Apr 2012 15:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIpC8SfzGPpq for ; Thu, 12 Apr 2012 15:14:53 -0700 (PDT) Received: from psmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) by ietfa.amsl.com (Postfix) with ESMTP id E0E6C21F875B for ; Thu, 12 Apr 2012 15:14:52 -0700 (PDT) Received: from mail-vx0-f181.google.com ([209.85.220.181]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKT4dT3F+IuebNQnz2zoYpBZAvQMYIM1Gq@postini.com; Thu, 12 Apr 2012 15:14:52 PDT Received: by vcge1 with SMTP id e1so2014163vcg.26 for ; Thu, 12 Apr 2012 15:14:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=SVEi5LIFyeJMScU2TKNk+2+tYIvLTupdhTEwQcDe8IA=; b=iMYbpQfKiLfrDwEBjP0ZaRQqfKqlaNeMgZ4u9zSei04wTkTjQVIrOlk17L0WHTwco9 +vw52/dUa6xi3BidQBTejYGiT1yIdOdo4FptbVZCM2f8CnW7EVmiNvEdfcVKt4wpkElW JyyzqevO/NqoU+VxEH6KBRPBdtWVYca3qTBh1uo2Ze3FOcznqho+f1Anrl1nRDzbbjn5 2nwsnNuQJ4XMuLHF+CL4BZBZibtEjNxNTlRuyyC8nKkHGWdNjM5aY2WYPey4UNPHfAD7 iJ9yaUliHIlzT6zeIL/qVj2zUykSBiCrPeLDFwNFna1+xJBKFz2zo7mAlxWa/qiRZbk1 eX9Q== Received: by 10.52.65.170 with SMTP id y10mr1717703vds.48.1334268891484; Thu, 12 Apr 2012 15:14:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.38.104 with HTTP; Thu, 12 Apr 2012 15:14:21 -0700 (PDT) In-Reply-To: <4F7DCE03.3020009@mitre.org> References: <999913AB42CC9341B05A99BBF358718D014D5CD1@FIESEXC035.nsn-intra.net> <4F7DCE03.3020009@mitre.org> From: Brian Campbell Date: Thu, 12 Apr 2012 16:14:21 -0600 Message-ID: To: Justin Richer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQndcb4bo1AJ1AZzNFKO8MUfYqjkq1hdyg7/z1/q826O/RQnVJ72VfHRxMasecdRIz82j5Q6 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] WGLC on Assertion Drafts 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: Thu, 12 Apr 2012 22:14:53 -0000 Thanks Justin, a couple comments/questions are inline... On Thu, Apr 5, 2012 at 10:53 AM, Justin Richer wrote: > > http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 > > > Section 7's second portion about a client including multiple credentials > types seems buried down here in the Error Responses section for something > this fundamental. Yeah, I can see that. Although the restriction on multiple client authentication methods is actually inherited from core OAuth (last sentence in http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.3) so maybe there shouldn't even normative language about it in this doc? > It also conflates discussion of selection of this client > authorization type in here, where it ought to be in its own section, clos= er > to the top. I'm not sure I follow you here? As I re-read =A77 I think it might make sense to break it into two pieces, one on grants and one on client auth. Maybe a 7.1 and a 7.2 or maybe subsections of =A74, like a =A74.1.1 for client authentication errors and =A74.2.1 for authz/grant errors. But I don't think that was what your comment was about? Was your comment that this text should live somewhere else? "Token endpoints can differentiate between assertion based credentials and other client credential types by looking for the presence of the client_assertion and client_assertion_type attributes which will only be present when using assertions for client authentication." I wouldn't disagree with you there, if that was the case. From romeda@gmail.com Thu Apr 12 15:41:06 2012 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 F23D121F85D9 for ; Thu, 12 Apr 2012 15:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.714 X-Spam-Level: X-Spam-Status: No, score=-102.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HnCuVEi0K33 for ; Thu, 12 Apr 2012 15:41:05 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 78CC321F85D7 for ; Thu, 12 Apr 2012 15:41:04 -0700 (PDT) Received: by lagj5 with SMTP id j5so2126615lag.31 for ; Thu, 12 Apr 2012 15:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=16U8/fDLhjvNYo9IAWlu0i2Ts7pQ2ibpY3hbktx23ac=; b=lHPEDE+uNrniT+vl/sEmp4OABBpBZGAkQX3QB5W5f/ylGkb3bL3XWG7GMgNlB7Ri/k 4JRuTYg7cCnyH6kiv4i7VGR3nn4hCKSTmetVGsb/4rimfRXq6rER2VOM9p3G7S4WvLT1 ROVd330dcT4Uv73MuN3UX9GPMvse2WZpASSVtWLr/3h2ayqR0/FC6os7E6aJXZS2gyMc LpT6JVtwLUrGwrJIsSJ+RqigV4+r0IQKiwj93ZufZYfdw18NNVFCMl9jn9ZEfMJPF9Rj PlErAnuEu1maTLKwszrxMKtVCsPgZ5gobjqvhwfzIkxMH/Lw4SJpGaQMqmHtEkhfw7hz LSAg== Received: by 10.152.105.241 with SMTP id gp17mr4031798lab.21.1334270463471; Thu, 12 Apr 2012 15:41:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.4.166 with HTTP; Thu, 12 Apr 2012 15:40:43 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366465919@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4E1F6AAD24975D4BA5B168042967394366465919@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Blaine Cook Date: Thu, 12 Apr 2012 18:40:43 -0400 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=f46d0407152b026f0704bd830dc3 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 12 Apr 2012 22:41:07 -0000 --f46d0407152b026f0704bd830dc3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12 April 2012 17:51, Mike Jones wrote: > Thanks for asking these questions Hannes. I'll first provide a brief > feature comparison of Simple Web Discovery and WebFinger and then answer > your questions. > > FEATURE COMPARISON > > RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: SWD returns the resource > location(s) for a specific resource for a specific principal. WebFinger > returns all resources for the principal. The example at > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2"R= etrieving a Person's Contact Information" is telling. The WebFinger > usage model seems to be "I'll get everything about you and then fish > through it to decide what to do with it." The protocol assumption that a= ll > WebFinger information must be public is also built into the protocol wher= e > the CORS response header "Access-Control-Allow-Origin: *" is mandated, pe= r > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7. > The privacy characteristics of these approaches are very different. (It= 's > these very same privacy characteristics that led sysadmins to nearly > ubiquitously disabling the fingerd service!) Particularly for the OAuth > use cases, narrow, scoped, and potentially permissioned responses seem > preferable. > This is absolutely false. SWD provides no privacy whatsoever. SWD makes it somewhat harder to crawl large numbers of profiles, but it does not incorporate any real security, and any attempt to suggest that it does is misleading and deceptive. Webfinger, like any good HTTP service, is designed to allow access control using appropriate means. That access control should not be *bound* to the protocol, in the same way that HTTP does not have any REQUIRED access control mechanisms, since doing so would severely restrict future usage of a core protocol. FUD has no place in a discussion of the technical and social merits of a protocol. For what it's worth, my intent with webfinger *from day one, nearly four years ago*, has been to provide permissioned profile data *using EXISTING* (or new, where appropriate or necessary, based on *running code and deployment EXPERIENCE*) access control mechanisms for profile data. The idea that there is ONE view of the data is patently false. For example, depending on who is requesting my profile data, I might return different contact telephone numbers, and this behaviour is completely feasible using webfinger. > DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURITY: WebFinger is > built on a "document model", where a single document is returned that > contains multiple resources for a principal. SWD is built on an "API > model", where the location(s) of a particular resource for a principal ar= e > returned. The problem with the document model is that different parties = or > services may be authoritative for different resources for a given > principal, and yet all need the rights to edit the resulting document. > This hurts deployability, because document edits then need to be > coordinated among parties that may have different rights and > responsibilities, and may have negative security implications as well. > (Just because I can change your avatar doesn't mean that I should be abl= e > to change your mail server.) > WS-* was built on an API model, and that worked out very well. APIs and documents on the web are the same thing; how you represent them behind the scenes is up to you, and that's been a core principle of the web since shortly after its inception. Suggesting otherwise profoundly misunderstands how implementation of web services happens. SWD says nothing of how to update profile data, so the security concerns here are a total red herring. > REDIRECT FUNCTIONALITY AND DEPLOYABILTY: SWD includes the ability to > redirect some or all SWD requests to another location (possibly depending > upon the specific resource and principal parameters). Deployers hosting > numerous sites for others told the SWD authors that this functionality is > critical for deployability, as it means that the SWD server for a domain > can live in a location outside the domain. WebFinger is lacking this > functionality. Given that OAuth is likely to be used in hosted > environments, this functionality seems pretty important. > Umm, I'm not even sure what to say to this. host-meta is a static file that points to a profile server (generally expected to be a dynamic "API" server) that can be hosted on any domain. The fact that you're suggesting that this core piece of webfinger functionality is *missing* seriously undermines my belief that you're acting in good faith, Mike. > NUMBER OF ROUND TRIPS: WebFinger discoveries for user information > normally require both a host-meta query to retrieve the template and then= a > second query to retrieve the user's information. This functionality is > achieved in a single SWD query. > ... at the cost of greater client complexity. A webfinger lookup may be implemented with the following trivial shell script: curl -s http://example.com/.well-known/host-meta|awk "/lrdd/,/template/"|tr -d '\n'|sed -e "s/^.*template=3D'\([^']*\)'.*$/\1/"|sed -e "s/{uri}/ user@example.com/"|xargs curl -s so long as your HTTP client properly follows redirects, this approach will always produce a valid webfinger profile, and if proper caching is implemented, will only make requests to /.well-known/host-meta when the document is expired. SWD, on the other hand, implements a non-HTTP redirect mechanism, meaning that optimal caching rules can't be obeyed by standard HTTP clients. Moreover, SWD *requires* conditionals by presenting one code path for the non-redirect case and one code path for the immediate response case. The complexity for client implementations should be foremost in this work, and the decisions made by SWD don't indicate to me that these factors have been considered. Indeed, I wonder why is SWD designed to pre-optimize for presumed scaling challenges that are faced by only the very largest providers (namely, the fact that two lookups are required for webfinger instead of one in the ideal case), when: 1. Those scaling challenges are simply not real threats. host-meta can be cached using existing HTTP mechanisms 2. The fact that SWD only returns one service definition per request means that more than one request will often be required to obtain the necessary information about a user. 3. The chances that Google or Microsoft will host dynamic response SWD services on the gmail.com or hotmail.com domains is next to nil, and will therefore need to issue redirects anyways. For smaller providers (e.g., personal domains hosted in static or rigid environments), hosting a SWD server at /.well-known/simple-web-discovery may be challenging indeed. Thus, all clients will need to support the redirect behaviour natively, and for those who write specs but not code, it is *more* complex to have conditional behaviour like that than to have a defined flow that is always followed. Further, it's more complex for small service providers to host static content that is invariant and properly cached (e.g., by transparent proxy caches like varnish and squid) when CGI parameters are appended, as with SWD. XML AND JSON VERSUS JSON: WebFinger specifies both XML and JSON support, > whereas SWD specifies only JSON. The SWD position is that it's simpler t= o > specify only one way of doing the same thing, with JSON being chosen > because it's simpler for developers to use than XML - the same decision a= s > made for the OAuth specs. > Webfinger only used XRD in the first place to satisfy the OpenID community. This is infuriating format-fetishism, and misses the point entirely. JSON is preferred, and I, for one, would happily modify host-meta and webfinger to require JSON is people feel this strongly about it. > DEFINING SPECIFIC RESOURCES: Besides specifying a discovery protocol, > WebFinger also defines specific resources and kinds of resources to be us= ed > with that protocol: the "acct" URI scheme, the "acct" Link Relation. > These should be considered on their own merits, but logically should be > decoupled from the discovery protocol into a different document or > documents. It's not clear these features would be needed in OAuth contex= ts. > I have long argued against the acct URI, but the consensus-based approach of the IETF has over-ridden me on that one. If you feel similarly, you are free to voice that opinion. It shocks me that you're saying that the OAuth WG shouldn't consider host-meta/webfinger because it defines something that isn't of interest to the OAuth WG. The whole point of my argument at the WG meeting in Paris was that Webfinger and SWD-like protocols are of such consequence to the web at large that the interests of the OAuth WG should not be used to define the parameters for their behaviour. I'm more convinced that you're using your power within this WG to have SWD rubber-stamped so that you can ship OpenID Connect as you've defined it. > QUESTIONS > > 1) Aren't these two mechanisms solving pretty much the same problem? > > They are solving an overlapping set of problems, but with > very different privacy characteristics, different deployability > characteristics, different security characteristics, and somewhat differe= nt > mechanisms. > Again, I totally disagree with your assessment here, Mike. > 2) Do we need to have two standards for the same functionality? > > No - Simple Web Discovery is sufficient for the OAuth use > cases (and likely for others as well). > I agree with this =E2=80=93 since SWD is an explicit (though unstated) fork= of Webfinger, there is no need to have two standards. > 3) Do you guys have a position or comments regarding either one of them? > > The functionality in Simple Web Discovery is minimal and > sufficient for the OAuth use cases, whereas some of the functionality and > assumptions made in WebFinger are harmful, both from a privacy and from a > deployability perspective. SWD should proceed to standardization; > WebFinger should not. I believe Mike has made misleading statements regarding the privacy and deployability perspective, either intentionally, or because he fundamentally does not understand the security or deployment scenarios that motivate the decisions. In summary: 1. I believe that SWD and Webfinger are essentially the same protocol, with different authors names at the top. 2. I don't care which one "wins", though I think that SWD's use of HTTP is questionable, and that the claims of privacy and deployability advantages offered by SWD are overblown and potentially misleading. 3. My concerns about SWD apply equally to any concerns anyone would leverage against Webfinger. 4. Which is to say, I think we should have one protocol that is defined by an open discussion. 5. We've had an open discussion on the webfinger list and apps-discuss and in the context of host-meta that the SWD folks have chosen not to engage with for the past three years. 6. The OAuth list is *not* the place for this discussion to happen, just so that Mike Jones can quickly push a spec through the formal process using a list that has well-known problems of too-high mail volume and whose topic is unrelated to the goals of Webfinger/SWD. This is important enough to get right, and getting it wrong will almost certainly lead to years of incompatibility and frustration, as Stephen mentioned. I encourage everyone involved to take this seriously, let go of personal attachment and presumptions of dependencies, and consider this work in an appropriate context (with an inclusive, not exclusive community)= . b. --f46d0407152b026f0704bd830dc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12 April 2012 17:51, Mike Jones <Michael.Jones@microsoft.com> wro= te:
Thanks for asking these questions Hannes. =C2=A0I'll first provide a br= ief feature comparison of Simple Web Discovery and WebFinger and then answe= r your questions.

FEATURE COMPARISON

RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: =C2=A0SWD returns the resou= rce location(s) for a specific resource for a specific principal. =C2=A0Web= Finger returns all resources for the principal. =C2=A0The example at http://tools.ietf.org/html/draft-jones-appsawg-webfing= er-03#section-3.2 "Retrieving a Person's Contact Information&q= uot; is telling. =C2=A0The WebFinger usage model seems to be "I'll= get everything about you and then fish through it to decide what to do wit= h it." =C2=A0The protocol assumption that all WebFinger information mu= st be public is also built into the protocol where the CORS response header= "Access-Control-Allow-Origin: *" is mandated, per http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#sec= tion-7. =C2=A0The privacy characteristics of these approaches are very = different. =C2=A0(It's these very same privacy characteristics that led= sysadmins to nearly ubiquitously disabling the fingerd service!) =C2=A0Par= ticularly for the OAuth use cases, narrow, scoped, and potentially permissi= oned responses seem preferable.

This is absolutely false.

SWD provides no privacy whatsoever. SWD makes it somewhat harder t= o crawl large numbers of profiles, but it does not incorporate any real sec= urity, and any attempt to suggest that it does is misleading and deceptive.=

Webfinger, like any good HTTP service, is designed to a= llow access control using appropriate means. That access control should not= be *bound* to the protocol, in the same way that HTTP does not have any RE= QUIRED access control mechanisms, since doing so would severely restrict fu= ture usage of a core protocol.

FUD has no place in a discussion of the technical and s= ocial merits of a protocol.

For what it's wort= h, my intent with webfinger *from day one, nearly four years ago*, has been= to provide permissioned profile data *using EXISTING* (or new, where appro= priate or necessary, based on *running code and deployment EXPERIENCE*) acc= ess control mechanisms for profile data.

The idea that there is ONE view of the data is patently= false. For example, depending on who is requesting my profile data, I migh= t return different contact telephone numbers, and this behaviour is complet= ely feasible using webfinger.
=C2=A0
DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURITY: =C2=A0WebFinger is = built on a "document model", where a single document is returned = that contains multiple resources for a principal. =C2=A0SWD is built on an = "API model", where the location(s) of a particular resource for a= principal are returned. =C2=A0The problem with the document model is that = different parties or services may be authoritative for different resources = for a given principal, and yet all need the rights to edit the resulting do= cument. =C2=A0This hurts deployability, because document edits then need to= be coordinated among parties that may have different rights and responsibi= lities, and may have negative security implications as well. =C2=A0(Just be= cause I can change your avatar doesn't mean that I should be able to ch= ange your mail server.)

WS-* was built on an API model, and that w= orked out very well.

APIs and documents on the web= are the same thing; how you represent them behind the scenes is up to you,= and that's been a core principle of the web since shortly after its in= ception. Suggesting otherwise profoundly misunderstands how implementation = of web services happens.

SWD says nothing of how to update profile data, so the = security concerns here are a total red herring.
=C2=A0
REDIRECT FUNCTIONALITY AND DEPLOYABILTY: =C2=A0SWD includes the ability to = redirect some or all SWD requests to another location (possibly depending u= pon the specific resource and principal parameters). =C2=A0Deployers hostin= g numerous sites for others told the SWD authors that this functionality is= critical for deployability, as it means that the SWD server for a domain c= an live in a location outside the domain. =C2=A0WebFinger is lacking this f= unctionality. =C2=A0Given that OAuth is likely to be used in hosted environ= ments, this functionality seems pretty important.

Umm, I'm not even sure what to say to = this. host-meta is a static file that points to a profile server (generally= expected to be a dynamic "API" server) that can be hosted on any= domain.

The fact that you're suggesting that this core piec= e of webfinger functionality is *missing* seriously undermines my belief th= at you're acting in good faith, Mike.
=C2=A0
NUMBER OF ROUND TRIPS: =C2=A0WebFinger discoveries for user information nor= mally require both a host-meta query to retrieve the template and then a se= cond query to retrieve the user's information. =C2=A0This functionality= is achieved in a single SWD query.

... at the cost of greater client complexi= ty. A webfinger lookup may be implemented with the following trivial shell = script:

curl -s http= ://example.com/.well-known/host-meta|awk "/lrdd/,/template/"|= tr -d '\n'|sed -e "s/^.*template=3D'\([^']*\)'.*$/= \1/"|sed -e "s/{uri}/user@ex= ample.com/"|xargs curl -s
=C2=A0
so long as your HTTP client properly follows redirect= s, this approach will always produce a valid webfinger profile, and if prop= er caching is implemented, will only make requests to /.well-known/host-met= a when the document is expired.

SWD, on the other hand, implements a non-HTTP redirect = mechanism, meaning that optimal caching rules can't be obeyed by standa= rd HTTP clients. Moreover, SWD *requires* conditionals by presenting one co= de path for the non-redirect case and one code path for the immediate respo= nse case.

The complexity for client implementations should be for= emost in this work, and the decisions made by SWD don't indicate to me = that these factors have been considered.

Indeed, I= wonder why=C2=A0is SWD designed to pre-optimize for presumed scaling chall= enges that are faced by only the very largest providers (namely, the fact t= hat two lookups are required for webfinger instead of one in the ideal case= ), when:

1. Those scaling challenges are simply not real threats= . host-meta can be cached using existing HTTP mechanisms
2. The f= act that SWD only returns one service definition per request means that mor= e than one request will often be required to obtain the necessary informati= on about a user.
3. The chances that Google or Microsoft will host dynamic response SWD= services on the gmail.com or hotmail.com domains is next to nil, and will therefo= re need to issue redirects anyways.

For smaller providers (e.g., personal domains hosted in= static or rigid environments), hosting a SWD server at /.well-known/simple= -web-discovery may be challenging indeed. Thus, all clients will need to su= pport the redirect behaviour natively, and for those who write specs but no= t code, it is *more* complex to have conditional behaviour like that than t= o have a defined flow that is always followed.

Further, it's more complex for small service provid= ers to host static content that is invariant and properly cached (e.g., by = transparent proxy caches like varnish and squid) when CGI parameters are ap= pended, as with SWD.

XML AND JSON VERSUS JSON: =C2=A0WebFinger specifies both XML and JSON suppo= rt, whereas SWD specifies only JSON. =C2=A0The SWD position is that it'= s simpler to specify only one way of doing the same thing, with JSON being = chosen because it's simpler for developers to use than XML - the same d= ecision as made for the OAuth specs.

Webfinger only used XRD in the first place= to satisfy the OpenID community. This is infuriating format-fetishism, and= misses the point entirely. JSON is preferred, and I, for one, would happil= y modify host-meta and webfinger to require JSON is people feel this strong= ly about it.
=C2=A0
DEFINING SPECIFIC RESOURCES= : =C2=A0Besides specifying a discovery protocol, WebFinger also defines spe= cific resources and kinds of resources to be used with that protocol: =C2= =A0the "acct" URI scheme, the "acct" Link Relation. =C2= =A0These should be considered on their own merits, but logically should be = decoupled from the discovery protocol into a different document or document= s. =C2=A0It's not clear these features would be needed in OAuth context= s.

I have long argued against the acct URI, b= ut the consensus-based approach of the IETF has over-ridden me on that one.= If you feel similarly, you are free to voice that opinion.

It shocks me that you're saying that the OAuth WG shouldn= 9;t consider host-meta/webfinger because it defines something that isn'= t of interest to the OAuth WG. The whole point of my argument at the WG mee= ting in Paris was that Webfinger and SWD-like protocols are of such consequ= ence to the web at large that the interests of the OAuth WG should not be u= sed to define the parameters for their behaviour.

I'm more convinced that you're using your power= within this WG to have SWD rubber-stamped so that you can ship OpenID Conn= ect as you've defined it.
=C2=A0
QUESTIONS

1) Aren't these two mechanisms solving pretty much the same problem?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 They are solving an= overlapping set of problems, but with very different privacy characteristi= cs, different deployability characteristics, different security characteris= tics, and somewhat different mechanisms.

Again, I totally disagree with your assess= ment here, Mike.
=C2=A0
2) Do we need to have two standards for the same function= ality?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 No - Simple Web Dis= covery is sufficient for the OAuth use cases (and likely for others as well= ).

I agree with this =E2=80=93 since SW= D is an explicit (though unstated) fork of Webfinger, there is no need to h= ave two standards.
=C2=A0
3) Do you guys have a position or comments regarding eith= er one of them?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The functionality i= n Simple Web Discovery is minimal and sufficient for the OAuth use cases, w= hereas some of the functionality and assumptions made in WebFinger are harm= ful, both from a privacy and from a deployability perspective. =C2=A0SWD sh= ould proceed to standardization; WebFinger should not.

I believe Mike has made misleading statements regarding= the privacy and deployability perspective, either intentionally, or becaus= e he fundamentally does not understand the security or deployment scenarios= that motivate the decisions.

In summary:

1. I believe that = SWD and Webfinger are essentially the same protocol, with different authors= names at the top.
2. I don't care which one "wins"= , though I think that SWD's use of HTTP is questionable, and that the c= laims of privacy and deployability advantages offered by SWD are overblown = and potentially misleading.
3. My concerns about SWD apply equally to any concerns anyone would le= verage against Webfinger.
4. Which is to say, I think we should h= ave one protocol that is defined by an open discussion.
5. We'= ;ve had an open discussion on the webfinger list and apps-discuss and in th= e context of host-meta that the SWD folks have chosen not to engage with fo= r the past three years.
6. The OAuth list is *not* the place for this discussion to happen, ju= st so that Mike Jones can quickly push a spec through the formal process us= ing a list that has well-known problems of too-high mail volume and whose t= opic is unrelated to the goals of Webfinger/SWD.

This is important enough to get right, and getting it w= rong will almost certainly lead to years of incompatibility and frustration= , as Stephen mentioned. I encourage everyone involved to take this seriousl= y, let go of personal attachment and presumptions of dependencies, and cons= ider this work in an appropriate context (with an inclusive, not exclusive = community).

b.
--f46d0407152b026f0704bd830dc3-- From hannes.tschofenig@gmx.net Fri Apr 13 07:36:05 2012 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 EEFEF21F868A for ; Fri, 13 Apr 2012 07:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEJZaWgeeOfr for ; Fri, 13 Apr 2012 07:36:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 11EE621F866A for ; Fri, 13 Apr 2012 07:36:04 -0700 (PDT) Received: (qmail invoked by alias); 13 Apr 2012 14:36:03 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp001) with SMTP; 13 Apr 2012 16:36:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/SKBwtDv7SqGWnLjjCjh9Br+h/CzwHx7mpP7dN9A pEUUUQa6ByNlbL From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2012 17:36:02 +0300 Message-Id: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Dynamic Client Registration 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: Fri, 13 Apr 2012 14:36:06 -0000 Hi all,=20 at the IETF#83 OAuth working group meeting we had some confusion about = the Dynamic Client Registration and the Simple Web Discovery item. I = just listened to the audio recording again.=20 With the ongoing mailing list discussion regarding WebFinger vs. Simple = Web Discovery I hope that folks had a chance to look at the documents = again and so the confusion of some got resolved. =20 I believe the proposed new charter item is sufficiently clear with = regard to the scope of the work. Right?=20 Here is the item again: " Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the = IESG for consideration as a Proposed Standard [Starting point for the work will be=20 http://tools.ietf.org/html/draft-hardjono-oauth-dynreg ]=20 " Of course there there is a relationship between Simple Web Discovery (or = WebFinger) and the dynamic client registration since the client first = needs to discover the client registration endpoint at the authorization = server before interacting with it.=20 Now, one thing that just came to my mind when looking again at = draft-hardjono-oauth-dynreq was the following: Could the Client = Registration Request and Response protocol exchange could become a = profile of the SCIM protocol? In some sense this exchange is nothing = else than provisioning an account at the Authorization Server (along = with some meta-data). Is this too far fetched?=20 Ciao Hannes From Michael.Jones@microsoft.com Fri Apr 13 09:18:14 2012 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 8521921F87F5 for ; Fri, 13 Apr 2012 09:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft398q8Yq2hV for ; Fri, 13 Apr 2012 09:18:12 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8452321F87F3 for ; Fri, 13 Apr 2012 09:18:11 -0700 (PDT) Received: from mail87-db3-R.bigfish.com (10.3.81.243) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Apr 2012 16:18:10 +0000 Received: from mail87-db3 (localhost [127.0.0.1]) by mail87-db3-R.bigfish.com (Postfix) with ESMTP id AE3C34602C9; Fri, 13 Apr 2012 16:18:10 +0000 (UTC) X-SpamScore: -34 X-BigFish: VS-34(zz9371Ic89bh1803M168aJ1418Ic857h98dK148cMzz1202hzz1033IL8275bh8275dh24b1kz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail87-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail87-db3 (localhost.localdomain [127.0.0.1]) by mail87-db3 (MessageSwitch) id 1334333887392680_13796; Fri, 13 Apr 2012 16:18:07 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.241]) by mail87-db3.bigfish.com (Postfix) with ESMTP id 5B7B920046; Fri, 13 Apr 2012 16:18:07 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Apr 2012 16:18:06 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0283.004; Fri, 13 Apr 2012 16:18:02 +0000 From: Mike Jones To: Blaine Cook Thread-Topic: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNGJt50G7JnMt5ukqcfN3YYKxyCZaXuy7ggAAOMYCAARDukA== Date: Fri, 13 Apr 2012 16:18:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436646671B@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4E1F6AAD24975D4BA5B168042967394366465919@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436646671BTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 13 Apr 2012 16:18:14 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436646671BTK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmxhaW5lLiAgSSBtdXN0IGFkbWl0LCBJ4oCZbSBwcmV0dHkgc3VycHJpc2VkIGJ5IHRoZSB0 b25lIG9mIHlvdXIgcmVwbHkuICBJ4oCZbGwgc2F5IHVwIGZyb250IHRoYXQgSSBoYXZlIGFic29s dXRlbHkgbm8gcHJvYmxlbSB3aXRoIGFueW9uZSBkaXNhZ3JlZWluZyB3aXRoIG1lIG9uIGEgdGVj aG5pY2FsIG9yIHRhY3RpY2FsIGJhc2lzLiAgSWYgeW91IHRoaW5rIEnigJltIHdyb25nLCBoYXZl IGF0IGl0Lg0KDQpCdXQgSSBhbSBwcmV0dHkgc2hvY2tlZCB0aGF0IHlvdSB3b3VsZCBkZWNpZGUg dG8gaW1wdWduIG15IG1vdGl2ZXMuICBXZeKAmXZlIG9ubHkgbWV0IHR3aWNlIGFuZCBib3RoIHRp bWVzIEkgdGhvdWdodCB3ZSBoYWQgcmVhbGx5IHVzZWZ1bCBhbmQgcHJvZHVjdGl2ZSBkaXNjdXNz aW9ucyBhYm91dCBob3cgdG8gbW92ZSBkaWdpdGFsIGlkZW50aXR5IG9uIHRoZSBXZWIgZm9yd2Fy ZCDigJMgc29tZXRoaW5nIEkgYmVsaWV2ZSB0aGF0IHdl4oCZcmUgYm90aCBwYXNzaW9uYXRlIGFi b3V0LiAgWW91IGRvbuKAmXQgcmVhbGx5IGtub3cgbWUsIHRob3VnaCwgd2hpY2ggaXMgYXBwYXJl bnQgZnJvbSB5b3VyIHJlbWFya3MgYmVsb3cuICBJIGJlbGlldmUgdGhhdCB0aG9zZSB3aG8gaGF2 ZSB3b3JrZWQgd2l0aCBtZSBmb3IgeWVhcnMgd291bGQgdm91Y2ggdGhhdCBJIGFtIGEgZm9ydGhy aWdodCBhbmQgZXZlbmhhbmRlZCBzdGFuZGFyZHMgcGFydGljaXBhbnQgd2hvIGxpc3RlbnMgdG8g YWxsIHBvaW50cyBvZiB2aWV3LCB0cmllcyB0byBidWlsZCBhIGNvbnNlbnN1cyB0aGF0IHdvcmtz LCBhbmQgcHJvZHVjZSBxdWFsaXR5IHJlc3VsdHMuDQoNCkkgdGhvdWdodCBhYm91dCB5b3VyIG5v dGUgb3Zlcm5pZ2h0IGFuZCB3aGV0aGVyIEkgc2hvdWxkIHJlcGx5IGF0IGFsbC4gIEnigJltIGZp bmUgd2l0aCBnaXZlIGFuZCB0YWtlLCBidXQgSSBiZWxpZXZlIHRoYXQgSSBuZWVkIHRvIHNheSB0 aGF0IGlmIHlvdSByZWFkIHdoYXQgeW91IHdyb3RlIGJlbG93LCBJIHRoaW5rIHlvdeKAmWxsIGFn cmVlIHRoYXQgdGhlIHRvbmUgeW91IHVzZWQgd2FzIGNvdW50ZXItcHJvZHVjdGl2ZSBhbmQgYW4g YXBvbG9neSBpcyBpbiBvcmRlci4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpQLlMuICBJ4oCZbGwgYWRkcmVz cyB5b3VyIHRlY2huaWNhbCBwb2ludHMgYmVsb3cgaW4gYSBzZXBhcmF0ZSBub3RlIGF0IHNvbWUg cG9pbnQg4oCTIHNvbWUgSSBhZ3JlZSB3aXRoIGFuZCBzb21lIEkgZG9u4oCZdC4gIEJ1dCBJIGZl bHQgdGhhdCBJIG5lZWRlZCB0byBhZGRyZXNzIG15IG1vdGl2ZXMgYmVpbmcgcXVlc3Rpb25lZCBz ZXBhcmF0ZWx5IGFuZCBmaXJzdC4gIEkgaG9wZSB3ZSBjYW4gYm90aCBjb21lIG91dCBvZiB0aGlz IHdpdGggYSBiZXR0ZXIgdW5kZXJzdGFuZGluZyBvZiBvbmUgYW5vdGhlciBhbmQgd29yayB0b2dl dGhlciB0b3dhcmRzIHRoZSBpbXBvcnRhbnQgZ29hbHMgdGhhdCB3ZSBib3RoIHNoYXJlLg0KDQpG cm9tOiBCbGFpbmUgQ29vayBbbWFpbHRvOnJvbWVkYUBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2Rh eSwgQXByaWwgMTIsIDIwMTIgMzo0MSBQTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBIYW5uZXMgVHNj aG9mZW5pZzsgb2F1dGhAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFdlYiBG aW5nZXIgdnMuIFNpbXBsZSBXZWIgRGlzY292ZXJ5IChTV0QpDQoNCk9uIDEyIEFwcmlsIDIwMTIg MTc6NTEsIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGFua3MgZm9yIGFza2luZyB0aGVz ZSBxdWVzdGlvbnMgSGFubmVzLiAgSSdsbCBmaXJzdCBwcm92aWRlIGEgYnJpZWYgZmVhdHVyZSBj b21wYXJpc29uIG9mIFNpbXBsZSBXZWIgRGlzY292ZXJ5IGFuZCBXZWJGaW5nZXIgYW5kIHRoZW4g YW5zd2VyIHlvdXIgcXVlc3Rpb25zLg0KDQpGRUFUVVJFIENPTVBBUklTT04NCg0KUkVTVUxUIEdS QU5VTEFSSVRZIEFORCBQUklWQUNZIENIQVJBQ1RFUklTVElDUzogIFNXRCByZXR1cm5zIHRoZSBy ZXNvdXJjZSBsb2NhdGlvbihzKSBmb3IgYSBzcGVjaWZpYyByZXNvdXJjZSBmb3IgYSBzcGVjaWZp YyBwcmluY2lwYWwuICBXZWJGaW5nZXIgcmV0dXJucyBhbGwgcmVzb3VyY2VzIGZvciB0aGUgcHJp bmNpcGFsLiAgVGhlIGV4YW1wbGUgYXQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt am9uZXMtYXBwc2F3Zy13ZWJmaW5nZXItMDMjc2VjdGlvbi0zLjIgIlJldHJpZXZpbmcgYSBQZXJz b24ncyBDb250YWN0IEluZm9ybWF0aW9uIiBpcyB0ZWxsaW5nLiAgVGhlIFdlYkZpbmdlciB1c2Fn ZSBtb2RlbCBzZWVtcyB0byBiZSAiSSdsbCBnZXQgZXZlcnl0aGluZyBhYm91dCB5b3UgYW5kIHRo ZW4gZmlzaCB0aHJvdWdoIGl0IHRvIGRlY2lkZSB3aGF0IHRvIGRvIHdpdGggaXQuIiAgVGhlIHBy b3RvY29sIGFzc3VtcHRpb24gdGhhdCBhbGwgV2ViRmluZ2VyIGluZm9ybWF0aW9uIG11c3QgYmUg cHVibGljIGlzIGFsc28gYnVpbHQgaW50byB0aGUgcHJvdG9jb2wgd2hlcmUgdGhlIENPUlMgcmVz cG9uc2UgaGVhZGVyICJBY2Nlc3MtQ29udHJvbC1BbGxvdy1PcmlnaW46ICoiIGlzIG1hbmRhdGVk LCBwZXIgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtYXBwc2F3Zy13ZWJm aW5nZXItMDMjc2VjdGlvbi03LiAgVGhlIHByaXZhY3kgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZXNl IGFwcHJvYWNoZXMgYXJlIHZlcnkgZGlmZmVyZW50LiAgKEl0J3MgdGhlc2UgdmVyeSBzYW1lIHBy aXZhY3kgY2hhcmFjdGVyaXN0aWNzIHRoYXQgbGVkIHN5c2FkbWlucyB0byBuZWFybHkgdWJpcXVp dG91c2x5IGRpc2FibGluZyB0aGUgZmluZ2VyZCBzZXJ2aWNlISkgIFBhcnRpY3VsYXJseSBmb3Ig dGhlIE9BdXRoIHVzZSBjYXNlcywgbmFycm93LCBzY29wZWQsIGFuZCBwb3RlbnRpYWxseSBwZXJt aXNzaW9uZWQgcmVzcG9uc2VzIHNlZW0gcHJlZmVyYWJsZS4NCg0KVGhpcyBpcyBhYnNvbHV0ZWx5 IGZhbHNlLg0KDQpTV0QgcHJvdmlkZXMgbm8gcHJpdmFjeSB3aGF0c29ldmVyLiBTV0QgbWFrZXMg aXQgc29tZXdoYXQgaGFyZGVyIHRvIGNyYXdsIGxhcmdlIG51bWJlcnMgb2YgcHJvZmlsZXMsIGJ1 dCBpdCBkb2VzIG5vdCBpbmNvcnBvcmF0ZSBhbnkgcmVhbCBzZWN1cml0eSwgYW5kIGFueSBhdHRl bXB0IHRvIHN1Z2dlc3QgdGhhdCBpdCBkb2VzIGlzIG1pc2xlYWRpbmcgYW5kIGRlY2VwdGl2ZS4N Cg0KV2ViZmluZ2VyLCBsaWtlIGFueSBnb29kIEhUVFAgc2VydmljZSwgaXMgZGVzaWduZWQgdG8g YWxsb3cgYWNjZXNzIGNvbnRyb2wgdXNpbmcgYXBwcm9wcmlhdGUgbWVhbnMuIFRoYXQgYWNjZXNz IGNvbnRyb2wgc2hvdWxkIG5vdCBiZSAqYm91bmQqIHRvIHRoZSBwcm90b2NvbCwgaW4gdGhlIHNh bWUgd2F5IHRoYXQgSFRUUCBkb2VzIG5vdCBoYXZlIGFueSBSRVFVSVJFRCBhY2Nlc3MgY29udHJv bCBtZWNoYW5pc21zLCBzaW5jZSBkb2luZyBzbyB3b3VsZCBzZXZlcmVseSByZXN0cmljdCBmdXR1 cmUgdXNhZ2Ugb2YgYSBjb3JlIHByb3RvY29sLg0KDQpGVUQgaGFzIG5vIHBsYWNlIGluIGEgZGlz Y3Vzc2lvbiBvZiB0aGUgdGVjaG5pY2FsIGFuZCBzb2NpYWwgbWVyaXRzIG9mIGEgcHJvdG9jb2wu DQoNCkZvciB3aGF0IGl0J3Mgd29ydGgsIG15IGludGVudCB3aXRoIHdlYmZpbmdlciAqZnJvbSBk YXkgb25lLCBuZWFybHkgZm91ciB5ZWFycyBhZ28qLCBoYXMgYmVlbiB0byBwcm92aWRlIHBlcm1p c3Npb25lZCBwcm9maWxlIGRhdGEgKnVzaW5nIEVYSVNUSU5HKiAob3IgbmV3LCB3aGVyZSBhcHBy b3ByaWF0ZSBvciBuZWNlc3NhcnksIGJhc2VkIG9uICpydW5uaW5nIGNvZGUgYW5kIGRlcGxveW1l bnQgRVhQRVJJRU5DRSopIGFjY2VzcyBjb250cm9sIG1lY2hhbmlzbXMgZm9yIHByb2ZpbGUgZGF0 YS4NCg0KVGhlIGlkZWEgdGhhdCB0aGVyZSBpcyBPTkUgdmlldyBvZiB0aGUgZGF0YSBpcyBwYXRl bnRseSBmYWxzZS4gRm9yIGV4YW1wbGUsIGRlcGVuZGluZyBvbiB3aG8gaXMgcmVxdWVzdGluZyBt eSBwcm9maWxlIGRhdGEsIEkgbWlnaHQgcmV0dXJuIGRpZmZlcmVudCBjb250YWN0IHRlbGVwaG9u ZSBudW1iZXJzLCBhbmQgdGhpcyBiZWhhdmlvdXIgaXMgY29tcGxldGVseSBmZWFzaWJsZSB1c2lu ZyB3ZWJmaW5nZXIuDQoNCkRPQ1VNRU5UIFZFUlNVUyBBUEkgTU9ERUwsIERFUExPWUFCSUxJVFks IEFORCBTRUNVUklUWTogIFdlYkZpbmdlciBpcyBidWlsdCBvbiBhICJkb2N1bWVudCBtb2RlbCIs IHdoZXJlIGEgc2luZ2xlIGRvY3VtZW50IGlzIHJldHVybmVkIHRoYXQgY29udGFpbnMgbXVsdGlw bGUgcmVzb3VyY2VzIGZvciBhIHByaW5jaXBhbC4gIFNXRCBpcyBidWlsdCBvbiBhbiAiQVBJIG1v ZGVsIiwgd2hlcmUgdGhlIGxvY2F0aW9uKHMpIG9mIGEgcGFydGljdWxhciByZXNvdXJjZSBmb3Ig YSBwcmluY2lwYWwgYXJlIHJldHVybmVkLiAgVGhlIHByb2JsZW0gd2l0aCB0aGUgZG9jdW1lbnQg bW9kZWwgaXMgdGhhdCBkaWZmZXJlbnQgcGFydGllcyBvciBzZXJ2aWNlcyBtYXkgYmUgYXV0aG9y aXRhdGl2ZSBmb3IgZGlmZmVyZW50IHJlc291cmNlcyBmb3IgYSBnaXZlbiBwcmluY2lwYWwsIGFu ZCB5ZXQgYWxsIG5lZWQgdGhlIHJpZ2h0cyB0byBlZGl0IHRoZSByZXN1bHRpbmcgZG9jdW1lbnQu ICBUaGlzIGh1cnRzIGRlcGxveWFiaWxpdHksIGJlY2F1c2UgZG9jdW1lbnQgZWRpdHMgdGhlbiBu ZWVkIHRvIGJlIGNvb3JkaW5hdGVkIGFtb25nIHBhcnRpZXMgdGhhdCBtYXkgaGF2ZSBkaWZmZXJl bnQgcmlnaHRzIGFuZCByZXNwb25zaWJpbGl0aWVzLCBhbmQgbWF5IGhhdmUgbmVnYXRpdmUgc2Vj dXJpdHkgaW1wbGljYXRpb25zIGFzIHdlbGwuICAoSnVzdCBiZWNhdXNlIEkgY2FuIGNoYW5nZSB5 b3VyIGF2YXRhciBkb2Vzbid0IG1lYW4gdGhhdCBJIHNob3VsZCBiZSBhYmxlIHRvIGNoYW5nZSB5 b3VyIG1haWwgc2VydmVyLikNCg0KV1MtKiB3YXMgYnVpbHQgb24gYW4gQVBJIG1vZGVsLCBhbmQg dGhhdCB3b3JrZWQgb3V0IHZlcnkgd2VsbC4NCg0KQVBJcyBhbmQgZG9jdW1lbnRzIG9uIHRoZSB3 ZWIgYXJlIHRoZSBzYW1lIHRoaW5nOyBob3cgeW91IHJlcHJlc2VudCB0aGVtIGJlaGluZCB0aGUg c2NlbmVzIGlzIHVwIHRvIHlvdSwgYW5kIHRoYXQncyBiZWVuIGEgY29yZSBwcmluY2lwbGUgb2Yg dGhlIHdlYiBzaW5jZSBzaG9ydGx5IGFmdGVyIGl0cyBpbmNlcHRpb24uIFN1Z2dlc3Rpbmcgb3Ro ZXJ3aXNlIHByb2ZvdW5kbHkgbWlzdW5kZXJzdGFuZHMgaG93IGltcGxlbWVudGF0aW9uIG9mIHdl YiBzZXJ2aWNlcyBoYXBwZW5zLg0KDQpTV0Qgc2F5cyBub3RoaW5nIG9mIGhvdyB0byB1cGRhdGUg cHJvZmlsZSBkYXRhLCBzbyB0aGUgc2VjdXJpdHkgY29uY2VybnMgaGVyZSBhcmUgYSB0b3RhbCBy ZWQgaGVycmluZy4NCg0KUkVESVJFQ1QgRlVOQ1RJT05BTElUWSBBTkQgREVQTE9ZQUJJTFRZOiAg U1dEIGluY2x1ZGVzIHRoZSBhYmlsaXR5IHRvIHJlZGlyZWN0IHNvbWUgb3IgYWxsIFNXRCByZXF1 ZXN0cyB0byBhbm90aGVyIGxvY2F0aW9uIChwb3NzaWJseSBkZXBlbmRpbmcgdXBvbiB0aGUgc3Bl Y2lmaWMgcmVzb3VyY2UgYW5kIHByaW5jaXBhbCBwYXJhbWV0ZXJzKS4gIERlcGxveWVycyBob3N0 aW5nIG51bWVyb3VzIHNpdGVzIGZvciBvdGhlcnMgdG9sZCB0aGUgU1dEIGF1dGhvcnMgdGhhdCB0 aGlzIGZ1bmN0aW9uYWxpdHkgaXMgY3JpdGljYWwgZm9yIGRlcGxveWFiaWxpdHksIGFzIGl0IG1l YW5zIHRoYXQgdGhlIFNXRCBzZXJ2ZXIgZm9yIGEgZG9tYWluIGNhbiBsaXZlIGluIGEgbG9jYXRp b24gb3V0c2lkZSB0aGUgZG9tYWluLiAgV2ViRmluZ2VyIGlzIGxhY2tpbmcgdGhpcyBmdW5jdGlv bmFsaXR5LiAgR2l2ZW4gdGhhdCBPQXV0aCBpcyBsaWtlbHkgdG8gYmUgdXNlZCBpbiBob3N0ZWQg ZW52aXJvbm1lbnRzLCB0aGlzIGZ1bmN0aW9uYWxpdHkgc2VlbXMgcHJldHR5IGltcG9ydGFudC4N Cg0KVW1tLCBJJ20gbm90IGV2ZW4gc3VyZSB3aGF0IHRvIHNheSB0byB0aGlzLiBob3N0LW1ldGEg aXMgYSBzdGF0aWMgZmlsZSB0aGF0IHBvaW50cyB0byBhIHByb2ZpbGUgc2VydmVyIChnZW5lcmFs bHkgZXhwZWN0ZWQgdG8gYmUgYSBkeW5hbWljICJBUEkiIHNlcnZlcikgdGhhdCBjYW4gYmUgaG9z dGVkIG9uIGFueSBkb21haW4uDQoNClRoZSBmYWN0IHRoYXQgeW91J3JlIHN1Z2dlc3RpbmcgdGhh dCB0aGlzIGNvcmUgcGllY2Ugb2Ygd2ViZmluZ2VyIGZ1bmN0aW9uYWxpdHkgaXMgKm1pc3Npbmcq IHNlcmlvdXNseSB1bmRlcm1pbmVzIG15IGJlbGllZiB0aGF0IHlvdSdyZSBhY3RpbmcgaW4gZ29v ZCBmYWl0aCwgTWlrZS4NCg0KTlVNQkVSIE9GIFJPVU5EIFRSSVBTOiAgV2ViRmluZ2VyIGRpc2Nv dmVyaWVzIGZvciB1c2VyIGluZm9ybWF0aW9uIG5vcm1hbGx5IHJlcXVpcmUgYm90aCBhIGhvc3Qt bWV0YSBxdWVyeSB0byByZXRyaWV2ZSB0aGUgdGVtcGxhdGUgYW5kIHRoZW4gYSBzZWNvbmQgcXVl cnkgdG8gcmV0cmlldmUgdGhlIHVzZXIncyBpbmZvcm1hdGlvbi4gIFRoaXMgZnVuY3Rpb25hbGl0 eSBpcyBhY2hpZXZlZCBpbiBhIHNpbmdsZSBTV0QgcXVlcnkuDQoNCi4uLiBhdCB0aGUgY29zdCBv ZiBncmVhdGVyIGNsaWVudCBjb21wbGV4aXR5LiBBIHdlYmZpbmdlciBsb29rdXAgbWF5IGJlIGlt cGxlbWVudGVkIHdpdGggdGhlIGZvbGxvd2luZyB0cml2aWFsIHNoZWxsIHNjcmlwdDoNCg0KY3Vy bCAtcyBodHRwOi8vZXhhbXBsZS5jb20vLndlbGwta25vd24vaG9zdC1tZXRhfGF3ayAiL2xyZGQv LC90ZW1wbGF0ZS8ifHRyIC1kICdcbid8c2VkIC1lICJzL14uKnRlbXBsYXRlPSdcKFteJ10qXCkn LiokL1wxLyJ8c2VkIC1lICJzL3t1cml9L3VzZXJAZXhhbXBsZS5jb20vPGh0dHA6Ly91c2VyQGV4 YW1wbGUuY29tLz4ifHhhcmdzIGN1cmwgLXMNCg0Kc28gbG9uZyBhcyB5b3VyIEhUVFAgY2xpZW50 IHByb3Blcmx5IGZvbGxvd3MgcmVkaXJlY3RzLCB0aGlzIGFwcHJvYWNoIHdpbGwgYWx3YXlzIHBy b2R1Y2UgYSB2YWxpZCB3ZWJmaW5nZXIgcHJvZmlsZSwgYW5kIGlmIHByb3BlciBjYWNoaW5nIGlz IGltcGxlbWVudGVkLCB3aWxsIG9ubHkgbWFrZSByZXF1ZXN0cyB0byAvLndlbGwta25vd24vaG9z dC1tZXRhIHdoZW4gdGhlIGRvY3VtZW50IGlzIGV4cGlyZWQuDQoNClNXRCwgb24gdGhlIG90aGVy IGhhbmQsIGltcGxlbWVudHMgYSBub24tSFRUUCByZWRpcmVjdCBtZWNoYW5pc20sIG1lYW5pbmcg dGhhdCBvcHRpbWFsIGNhY2hpbmcgcnVsZXMgY2FuJ3QgYmUgb2JleWVkIGJ5IHN0YW5kYXJkIEhU VFAgY2xpZW50cy4gTW9yZW92ZXIsIFNXRCAqcmVxdWlyZXMqIGNvbmRpdGlvbmFscyBieSBwcmVz ZW50aW5nIG9uZSBjb2RlIHBhdGggZm9yIHRoZSBub24tcmVkaXJlY3QgY2FzZSBhbmQgb25lIGNv ZGUgcGF0aCBmb3IgdGhlIGltbWVkaWF0ZSByZXNwb25zZSBjYXNlLg0KDQpUaGUgY29tcGxleGl0 eSBmb3IgY2xpZW50IGltcGxlbWVudGF0aW9ucyBzaG91bGQgYmUgZm9yZW1vc3QgaW4gdGhpcyB3 b3JrLCBhbmQgdGhlIGRlY2lzaW9ucyBtYWRlIGJ5IFNXRCBkb24ndCBpbmRpY2F0ZSB0byBtZSB0 aGF0IHRoZXNlIGZhY3RvcnMgaGF2ZSBiZWVuIGNvbnNpZGVyZWQuDQoNCkluZGVlZCwgSSB3b25k ZXIgd2h5IGlzIFNXRCBkZXNpZ25lZCB0byBwcmUtb3B0aW1pemUgZm9yIHByZXN1bWVkIHNjYWxp bmcgY2hhbGxlbmdlcyB0aGF0IGFyZSBmYWNlZCBieSBvbmx5IHRoZSB2ZXJ5IGxhcmdlc3QgcHJv dmlkZXJzIChuYW1lbHksIHRoZSBmYWN0IHRoYXQgdHdvIGxvb2t1cHMgYXJlIHJlcXVpcmVkIGZv ciB3ZWJmaW5nZXIgaW5zdGVhZCBvZiBvbmUgaW4gdGhlIGlkZWFsIGNhc2UpLCB3aGVuOg0KDQox LiBUaG9zZSBzY2FsaW5nIGNoYWxsZW5nZXMgYXJlIHNpbXBseSBub3QgcmVhbCB0aHJlYXRzLiBo b3N0LW1ldGEgY2FuIGJlIGNhY2hlZCB1c2luZyBleGlzdGluZyBIVFRQIG1lY2hhbmlzbXMNCjIu IFRoZSBmYWN0IHRoYXQgU1dEIG9ubHkgcmV0dXJucyBvbmUgc2VydmljZSBkZWZpbml0aW9uIHBl ciByZXF1ZXN0IG1lYW5zIHRoYXQgbW9yZSB0aGFuIG9uZSByZXF1ZXN0IHdpbGwgb2Z0ZW4gYmUg cmVxdWlyZWQgdG8gb2J0YWluIHRoZSBuZWNlc3NhcnkgaW5mb3JtYXRpb24gYWJvdXQgYSB1c2Vy Lg0KMy4gVGhlIGNoYW5jZXMgdGhhdCBHb29nbGUgb3IgTWljcm9zb2Z0IHdpbGwgaG9zdCBkeW5h bWljIHJlc3BvbnNlIFNXRCBzZXJ2aWNlcyBvbiB0aGUgZ21haWwuY29tPGh0dHA6Ly9nbWFpbC5j b20+IG9yIGhvdG1haWwuY29tPGh0dHA6Ly9ob3RtYWlsLmNvbT4gZG9tYWlucyBpcyBuZXh0IHRv IG5pbCwgYW5kIHdpbGwgdGhlcmVmb3JlIG5lZWQgdG8gaXNzdWUgcmVkaXJlY3RzIGFueXdheXMu DQoNCkZvciBzbWFsbGVyIHByb3ZpZGVycyAoZS5nLiwgcGVyc29uYWwgZG9tYWlucyBob3N0ZWQg aW4gc3RhdGljIG9yIHJpZ2lkIGVudmlyb25tZW50cyksIGhvc3RpbmcgYSBTV0Qgc2VydmVyIGF0 IC8ud2VsbC1rbm93bi9zaW1wbGUtd2ViLWRpc2NvdmVyeSBtYXkgYmUgY2hhbGxlbmdpbmcgaW5k ZWVkLiBUaHVzLCBhbGwgY2xpZW50cyB3aWxsIG5lZWQgdG8gc3VwcG9ydCB0aGUgcmVkaXJlY3Qg YmVoYXZpb3VyIG5hdGl2ZWx5LCBhbmQgZm9yIHRob3NlIHdobyB3cml0ZSBzcGVjcyBidXQgbm90 IGNvZGUsIGl0IGlzICptb3JlKiBjb21wbGV4IHRvIGhhdmUgY29uZGl0aW9uYWwgYmVoYXZpb3Vy IGxpa2UgdGhhdCB0aGFuIHRvIGhhdmUgYSBkZWZpbmVkIGZsb3cgdGhhdCBpcyBhbHdheXMgZm9s bG93ZWQuDQoNCkZ1cnRoZXIsIGl0J3MgbW9yZSBjb21wbGV4IGZvciBzbWFsbCBzZXJ2aWNlIHBy b3ZpZGVycyB0byBob3N0IHN0YXRpYyBjb250ZW50IHRoYXQgaXMgaW52YXJpYW50IGFuZCBwcm9w ZXJseSBjYWNoZWQgKGUuZy4sIGJ5IHRyYW5zcGFyZW50IHByb3h5IGNhY2hlcyBsaWtlIHZhcm5p c2ggYW5kIHNxdWlkKSB3aGVuIENHSSBwYXJhbWV0ZXJzIGFyZSBhcHBlbmRlZCwgYXMgd2l0aCBT V0QuDQoNClhNTCBBTkQgSlNPTiBWRVJTVVMgSlNPTjogIFdlYkZpbmdlciBzcGVjaWZpZXMgYm90 aCBYTUwgYW5kIEpTT04gc3VwcG9ydCwgd2hlcmVhcyBTV0Qgc3BlY2lmaWVzIG9ubHkgSlNPTi4g IFRoZSBTV0QgcG9zaXRpb24gaXMgdGhhdCBpdCdzIHNpbXBsZXIgdG8gc3BlY2lmeSBvbmx5IG9u ZSB3YXkgb2YgZG9pbmcgdGhlIHNhbWUgdGhpbmcsIHdpdGggSlNPTiBiZWluZyBjaG9zZW4gYmVj YXVzZSBpdCdzIHNpbXBsZXIgZm9yIGRldmVsb3BlcnMgdG8gdXNlIHRoYW4gWE1MIC0gdGhlIHNh bWUgZGVjaXNpb24gYXMgbWFkZSBmb3IgdGhlIE9BdXRoIHNwZWNzLg0KDQpXZWJmaW5nZXIgb25s eSB1c2VkIFhSRCBpbiB0aGUgZmlyc3QgcGxhY2UgdG8gc2F0aXNmeSB0aGUgT3BlbklEIGNvbW11 bml0eS4gVGhpcyBpcyBpbmZ1cmlhdGluZyBmb3JtYXQtZmV0aXNoaXNtLCBhbmQgbWlzc2VzIHRo ZSBwb2ludCBlbnRpcmVseS4gSlNPTiBpcyBwcmVmZXJyZWQsIGFuZCBJLCBmb3Igb25lLCB3b3Vs ZCBoYXBwaWx5IG1vZGlmeSBob3N0LW1ldGEgYW5kIHdlYmZpbmdlciB0byByZXF1aXJlIEpTT04g aXMgcGVvcGxlIGZlZWwgdGhpcyBzdHJvbmdseSBhYm91dCBpdC4NCg0KREVGSU5JTkcgU1BFQ0lG SUMgUkVTT1VSQ0VTOiAgQmVzaWRlcyBzcGVjaWZ5aW5nIGEgZGlzY292ZXJ5IHByb3RvY29sLCBX ZWJGaW5nZXIgYWxzbyBkZWZpbmVzIHNwZWNpZmljIHJlc291cmNlcyBhbmQga2luZHMgb2YgcmVz b3VyY2VzIHRvIGJlIHVzZWQgd2l0aCB0aGF0IHByb3RvY29sOiAgdGhlICJhY2N0IiBVUkkgc2No ZW1lLCB0aGUgImFjY3QiIExpbmsgUmVsYXRpb24uICBUaGVzZSBzaG91bGQgYmUgY29uc2lkZXJl ZCBvbiB0aGVpciBvd24gbWVyaXRzLCBidXQgbG9naWNhbGx5IHNob3VsZCBiZSBkZWNvdXBsZWQg ZnJvbSB0aGUgZGlzY292ZXJ5IHByb3RvY29sIGludG8gYSBkaWZmZXJlbnQgZG9jdW1lbnQgb3Ig ZG9jdW1lbnRzLiAgSXQncyBub3QgY2xlYXIgdGhlc2UgZmVhdHVyZXMgd291bGQgYmUgbmVlZGVk IGluIE9BdXRoIGNvbnRleHRzLg0KDQpJIGhhdmUgbG9uZyBhcmd1ZWQgYWdhaW5zdCB0aGUgYWNj dCBVUkksIGJ1dCB0aGUgY29uc2Vuc3VzLWJhc2VkIGFwcHJvYWNoIG9mIHRoZSBJRVRGIGhhcyBv dmVyLXJpZGRlbiBtZSBvbiB0aGF0IG9uZS4gSWYgeW91IGZlZWwgc2ltaWxhcmx5LCB5b3UgYXJl IGZyZWUgdG8gdm9pY2UgdGhhdCBvcGluaW9uLg0KDQpJdCBzaG9ja3MgbWUgdGhhdCB5b3UncmUg c2F5aW5nIHRoYXQgdGhlIE9BdXRoIFdHIHNob3VsZG4ndCBjb25zaWRlciBob3N0LW1ldGEvd2Vi ZmluZ2VyIGJlY2F1c2UgaXQgZGVmaW5lcyBzb21ldGhpbmcgdGhhdCBpc24ndCBvZiBpbnRlcmVz dCB0byB0aGUgT0F1dGggV0cuIFRoZSB3aG9sZSBwb2ludCBvZiBteSBhcmd1bWVudCBhdCB0aGUg V0cgbWVldGluZyBpbiBQYXJpcyB3YXMgdGhhdCBXZWJmaW5nZXIgYW5kIFNXRC1saWtlIHByb3Rv Y29scyBhcmUgb2Ygc3VjaCBjb25zZXF1ZW5jZSB0byB0aGUgd2ViIGF0IGxhcmdlIHRoYXQgdGhl IGludGVyZXN0cyBvZiB0aGUgT0F1dGggV0cgc2hvdWxkIG5vdCBiZSB1c2VkIHRvIGRlZmluZSB0 aGUgcGFyYW1ldGVycyBmb3IgdGhlaXIgYmVoYXZpb3VyLg0KDQpJJ20gbW9yZSBjb252aW5jZWQg dGhhdCB5b3UncmUgdXNpbmcgeW91ciBwb3dlciB3aXRoaW4gdGhpcyBXRyB0byBoYXZlIFNXRCBy dWJiZXItc3RhbXBlZCBzbyB0aGF0IHlvdSBjYW4gc2hpcCBPcGVuSUQgQ29ubmVjdCBhcyB5b3Un dmUgZGVmaW5lZCBpdC4NCg0KUVVFU1RJT05TDQoNCjEpIEFyZW4ndCB0aGVzZSB0d28gbWVjaGFu aXNtcyBzb2x2aW5nIHByZXR0eSBtdWNoIHRoZSBzYW1lIHByb2JsZW0/DQogICAgICAgICAgICAg IFRoZXkgYXJlIHNvbHZpbmcgYW4gb3ZlcmxhcHBpbmcgc2V0IG9mIHByb2JsZW1zLCBidXQgd2l0 aCB2ZXJ5IGRpZmZlcmVudCBwcml2YWN5IGNoYXJhY3RlcmlzdGljcywgZGlmZmVyZW50IGRlcGxv eWFiaWxpdHkgY2hhcmFjdGVyaXN0aWNzLCBkaWZmZXJlbnQgc2VjdXJpdHkgY2hhcmFjdGVyaXN0 aWNzLCBhbmQgc29tZXdoYXQgZGlmZmVyZW50IG1lY2hhbmlzbXMuDQoNCkFnYWluLCBJIHRvdGFs bHkgZGlzYWdyZWUgd2l0aCB5b3VyIGFzc2Vzc21lbnQgaGVyZSwgTWlrZS4NCg0KMikgRG8gd2Ug bmVlZCB0byBoYXZlIHR3byBzdGFuZGFyZHMgZm9yIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHk/DQog ICAgICAgICAgICAgIE5vIC0gU2ltcGxlIFdlYiBEaXNjb3ZlcnkgaXMgc3VmZmljaWVudCBmb3Ig dGhlIE9BdXRoIHVzZSBjYXNlcyAoYW5kIGxpa2VseSBmb3Igb3RoZXJzIGFzIHdlbGwpLg0KDQpJ IGFncmVlIHdpdGggdGhpcyDigJMgc2luY2UgU1dEIGlzIGFuIGV4cGxpY2l0ICh0aG91Z2ggdW5z dGF0ZWQpIGZvcmsgb2YgV2ViZmluZ2VyLCB0aGVyZSBpcyBubyBuZWVkIHRvIGhhdmUgdHdvIHN0 YW5kYXJkcy4NCg0KMykgRG8geW91IGd1eXMgaGF2ZSBhIHBvc2l0aW9uIG9yIGNvbW1lbnRzIHJl Z2FyZGluZyBlaXRoZXIgb25lIG9mIHRoZW0/DQogICAgICAgICAgICAgIFRoZSBmdW5jdGlvbmFs aXR5IGluIFNpbXBsZSBXZWIgRGlzY292ZXJ5IGlzIG1pbmltYWwgYW5kIHN1ZmZpY2llbnQgZm9y IHRoZSBPQXV0aCB1c2UgY2FzZXMsIHdoZXJlYXMgc29tZSBvZiB0aGUgZnVuY3Rpb25hbGl0eSBh bmQgYXNzdW1wdGlvbnMgbWFkZSBpbiBXZWJGaW5nZXIgYXJlIGhhcm1mdWwsIGJvdGggZnJvbSBh IHByaXZhY3kgYW5kIGZyb20gYSBkZXBsb3lhYmlsaXR5IHBlcnNwZWN0aXZlLiAgU1dEIHNob3Vs ZCBwcm9jZWVkIHRvIHN0YW5kYXJkaXphdGlvbjsgV2ViRmluZ2VyIHNob3VsZCBub3QuDQoNCkkg YmVsaWV2ZSBNaWtlIGhhcyBtYWRlIG1pc2xlYWRpbmcgc3RhdGVtZW50cyByZWdhcmRpbmcgdGhl IHByaXZhY3kgYW5kIGRlcGxveWFiaWxpdHkgcGVyc3BlY3RpdmUsIGVpdGhlciBpbnRlbnRpb25h bGx5LCBvciBiZWNhdXNlIGhlIGZ1bmRhbWVudGFsbHkgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUg c2VjdXJpdHkgb3IgZGVwbG95bWVudCBzY2VuYXJpb3MgdGhhdCBtb3RpdmF0ZSB0aGUgZGVjaXNp b25zLg0KDQpJbiBzdW1tYXJ5Og0KDQoxLiBJIGJlbGlldmUgdGhhdCBTV0QgYW5kIFdlYmZpbmdl ciBhcmUgZXNzZW50aWFsbHkgdGhlIHNhbWUgcHJvdG9jb2wsIHdpdGggZGlmZmVyZW50IGF1dGhv cnMgbmFtZXMgYXQgdGhlIHRvcC4NCjIuIEkgZG9uJ3QgY2FyZSB3aGljaCBvbmUgIndpbnMiLCB0 aG91Z2ggSSB0aGluayB0aGF0IFNXRCdzIHVzZSBvZiBIVFRQIGlzIHF1ZXN0aW9uYWJsZSwgYW5k IHRoYXQgdGhlIGNsYWltcyBvZiBwcml2YWN5IGFuZCBkZXBsb3lhYmlsaXR5IGFkdmFudGFnZXMg b2ZmZXJlZCBieSBTV0QgYXJlIG92ZXJibG93biBhbmQgcG90ZW50aWFsbHkgbWlzbGVhZGluZy4N CjMuIE15IGNvbmNlcm5zIGFib3V0IFNXRCBhcHBseSBlcXVhbGx5IHRvIGFueSBjb25jZXJucyBh bnlvbmUgd291bGQgbGV2ZXJhZ2UgYWdhaW5zdCBXZWJmaW5nZXIuDQo0LiBXaGljaCBpcyB0byBz YXksIEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgb25lIHByb3RvY29sIHRoYXQgaXMgZGVmaW5lZCBi eSBhbiBvcGVuIGRpc2N1c3Npb24uDQo1LiBXZSd2ZSBoYWQgYW4gb3BlbiBkaXNjdXNzaW9uIG9u IHRoZSB3ZWJmaW5nZXIgbGlzdCBhbmQgYXBwcy1kaXNjdXNzIGFuZCBpbiB0aGUgY29udGV4dCBv ZiBob3N0LW1ldGEgdGhhdCB0aGUgU1dEIGZvbGtzIGhhdmUgY2hvc2VuIG5vdCB0byBlbmdhZ2Ug d2l0aCBmb3IgdGhlIHBhc3QgdGhyZWUgeWVhcnMuDQo2LiBUaGUgT0F1dGggbGlzdCBpcyAqbm90 KiB0aGUgcGxhY2UgZm9yIHRoaXMgZGlzY3Vzc2lvbiB0byBoYXBwZW4sIGp1c3Qgc28gdGhhdCBN aWtlIEpvbmVzIGNhbiBxdWlja2x5IHB1c2ggYSBzcGVjIHRocm91Z2ggdGhlIGZvcm1hbCBwcm9j ZXNzIHVzaW5nIGEgbGlzdCB0aGF0IGhhcyB3ZWxsLWtub3duIHByb2JsZW1zIG9mIHRvby1oaWdo IG1haWwgdm9sdW1lIGFuZCB3aG9zZSB0b3BpYyBpcyB1bnJlbGF0ZWQgdG8gdGhlIGdvYWxzIG9m IFdlYmZpbmdlci9TV0QuDQoNClRoaXMgaXMgaW1wb3J0YW50IGVub3VnaCB0byBnZXQgcmlnaHQs IGFuZCBnZXR0aW5nIGl0IHdyb25nIHdpbGwgYWxtb3N0IGNlcnRhaW5seSBsZWFkIHRvIHllYXJz IG9mIGluY29tcGF0aWJpbGl0eSBhbmQgZnJ1c3RyYXRpb24sIGFzIFN0ZXBoZW4gbWVudGlvbmVk LiBJIGVuY291cmFnZSBldmVyeW9uZSBpbnZvbHZlZCB0byB0YWtlIHRoaXMgc2VyaW91c2x5LCBs ZXQgZ28gb2YgcGVyc29uYWwgYXR0YWNobWVudCBhbmQgcHJlc3VtcHRpb25zIG9mIGRlcGVuZGVu Y2llcywgYW5kIGNvbnNpZGVyIHRoaXMgd29yayBpbiBhbiBhcHByb3ByaWF0ZSBjb250ZXh0ICh3 aXRoIGFuIGluY2x1c2l2ZSwgbm90IGV4Y2x1c2l2ZSBjb21tdW5pdHkpLg0KDQpiLg0K --_000_4E1F6AAD24975D4BA5B16804296739436646671BTK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQmxhaW5lLiZuYnNw OyBJIG11c3QgYWRtaXQsIEnigJltIHByZXR0eSBzdXJwcmlzZWQgYnkgdGhlIHRvbmUgb2YgeW91 ciByZXBseS4mbmJzcDsgSeKAmWxsIHNheSB1cCBmcm9udCB0aGF0IEkgaGF2ZSBhYnNvbHV0ZWx5 IG5vIHByb2JsZW0gd2l0aCBhbnlvbmUgZGlzYWdyZWVpbmcgd2l0aA0KIG1lIG9uIGEgdGVjaG5p Y2FsIG9yIHRhY3RpY2FsIGJhc2lzLiZuYnNwOyBJZiB5b3UgdGhpbmsgSeKAmW0gd3JvbmcsIGhh dmUgYXQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5CdXQgSSBhbSBwcmV0dHkgc2hvY2tlZCB0aGF0IHlvdSB3b3Vs ZCBkZWNpZGUgdG8gaW1wdWduIG15IG1vdGl2ZXMuJm5ic3A7IFdl4oCZdmUgb25seSBtZXQgdHdp Y2UgYW5kIGJvdGggdGltZXMgSSB0aG91Z2h0IHdlIGhhZCByZWFsbHkgdXNlZnVsIGFuZCBwcm9k dWN0aXZlIGRpc2N1c3Npb25zDQogYWJvdXQgaG93IHRvIG1vdmUgZGlnaXRhbCBpZGVudGl0eSBv biB0aGUgV2ViIGZvcndhcmQg4oCTIHNvbWV0aGluZyBJIGJlbGlldmUgdGhhdCB3ZeKAmXJlIGJv dGggcGFzc2lvbmF0ZSBhYm91dC4mbmJzcDsgWW91IGRvbuKAmXQgcmVhbGx5IGtub3cgbWUsIHRo b3VnaCwgd2hpY2ggaXMgYXBwYXJlbnQgZnJvbSB5b3VyIHJlbWFya3MgYmVsb3cuJm5ic3A7IEkg YmVsaWV2ZSB0aGF0IHRob3NlIHdobyBoYXZlIHdvcmtlZCB3aXRoIG1lIGZvciB5ZWFycyB3b3Vs ZCB2b3VjaA0KIHRoYXQgSSBhbSBhIGZvcnRocmlnaHQgYW5kIGV2ZW5oYW5kZWQgc3RhbmRhcmRz IHBhcnRpY2lwYW50IHdobyBsaXN0ZW5zIHRvIGFsbCBwb2ludHMgb2YgdmlldywgdHJpZXMgdG8g YnVpbGQgYSBjb25zZW5zdXMgdGhhdCB3b3JrcywgYW5kIHByb2R1Y2UgcXVhbGl0eSByZXN1bHRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSB0aG91Z2h0IGFib3V0IHlvdXIgbm90ZSBvdmVybmlnaHQgYW5kIHdoZXRo ZXIgSSBzaG91bGQgcmVwbHkgYXQgYWxsLiZuYnNwOyBJ4oCZbSBmaW5lIHdpdGggZ2l2ZSBhbmQg dGFrZSwgYnV0IEkgYmVsaWV2ZSB0aGF0IEkgbmVlZCB0byBzYXkgdGhhdCBpZiB5b3UgcmVhZCB3 aGF0DQogeW91IHdyb3RlIGJlbG93LCBJIHRoaW5rIHlvdeKAmWxsIGFncmVlIHRoYXQgdGhlIHRv bmUgeW91IHVzZWQgd2FzIGNvdW50ZXItcHJvZHVjdGl2ZSBhbmQgYW4gYXBvbG9neSBpcyBpbiBv cmRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QLlMuJm5ic3A7 IEnigJlsbCBhZGRyZXNzIHlvdXIgdGVjaG5pY2FsIHBvaW50cyBiZWxvdyBpbiBhIHNlcGFyYXRl IG5vdGUgYXQgc29tZSBwb2ludCDigJMgc29tZSBJIGFncmVlIHdpdGggYW5kIHNvbWUgSSBkb27i gJl0LiZuYnNwOyBCdXQgSSBmZWx0IHRoYXQgSSBuZWVkZWQgdG8gYWRkcmVzcyBteQ0KIG1vdGl2 ZXMgYmVpbmcgcXVlc3Rpb25lZCBzZXBhcmF0ZWx5IGFuZCBmaXJzdC4mbmJzcDsgSSBob3BlIHdl IGNhbiBib3RoIGNvbWUgb3V0IG9mIHRoaXMgd2l0aCBhIGJldHRlciB1bmRlcnN0YW5kaW5nIG9m IG9uZSBhbm90aGVyIGFuZCB3b3JrIHRvZ2V0aGVyIHRvd2FyZHMgdGhlIGltcG9ydGFudCBnb2Fs cyB0aGF0IHdlIGJvdGggc2hhcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBCbGFpbmUgQ29vayBbbWFpbHRvOnJvbWVkYUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDEyLCAyMDEyIDM6NDEgUE08YnI+DQo8Yj5Ubzo8L2I+ IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IEhhbm5lcyBUc2Nob2ZlbmlnOyBvYXV0aEBpZXRm Lm9yZyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBXZWIgRmluZ2VyIHZz LiBTaW1wbGUgV2ViIERpc2NvdmVyeSAoU1dEKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gMTIgQXByaWwgMjAxMiAxNzo1MSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgYXNraW5nIHRoZXNlIHF1ZXN0aW9ucyBIYW5uZXMu ICZuYnNwO0knbGwgZmlyc3QgcHJvdmlkZSBhIGJyaWVmIGZlYXR1cmUgY29tcGFyaXNvbiBvZiBT aW1wbGUgV2ViIERpc2NvdmVyeSBhbmQgV2ViRmluZ2VyIGFuZCB0aGVuIGFuc3dlciB5b3VyIHF1 ZXN0aW9ucy48YnI+DQo8YnI+DQpGRUFUVVJFIENPTVBBUklTT048YnI+DQo8YnI+DQpSRVNVTFQg R1JBTlVMQVJJVFkgQU5EIFBSSVZBQ1kgQ0hBUkFDVEVSSVNUSUNTOiAmbmJzcDtTV0QgcmV0dXJu cyB0aGUgcmVzb3VyY2UgbG9jYXRpb24ocykgZm9yIGEgc3BlY2lmaWMgcmVzb3VyY2UgZm9yIGEg c3BlY2lmaWMgcHJpbmNpcGFsLiAmbmJzcDtXZWJGaW5nZXIgcmV0dXJucyBhbGwgcmVzb3VyY2Vz IGZvciB0aGUgcHJpbmNpcGFsLiAmbmJzcDtUaGUgZXhhbXBsZSBhdA0KPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtYXBwc2F3Zy13ZWJmaW5nZXItMDMjc2Vj dGlvbi0zLjIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWpvbmVzLWFwcHNhd2ctd2ViZmluZ2VyLTAzI3NlY3Rpb24tMy4yPC9hPiAmcXVvdDtSZXRy aWV2aW5nIGEgUGVyc29uJ3MgQ29udGFjdCBJbmZvcm1hdGlvbiZxdW90OyBpcyB0ZWxsaW5nLiAm bmJzcDtUaGUgV2ViRmluZ2VyIHVzYWdlIG1vZGVsIHNlZW1zIHRvIGJlICZxdW90O0knbGwgZ2V0 IGV2ZXJ5dGhpbmcgYWJvdXQgeW91IGFuZCB0aGVuIGZpc2ggdGhyb3VnaCBpdCB0byBkZWNpZGUg d2hhdCB0byBkbyB3aXRoIGl0LiZxdW90Ow0KICZuYnNwO1RoZSBwcm90b2NvbCBhc3N1bXB0aW9u IHRoYXQgYWxsIFdlYkZpbmdlciBpbmZvcm1hdGlvbiBtdXN0IGJlIHB1YmxpYyBpcyBhbHNvIGJ1 aWx0IGludG8gdGhlIHByb3RvY29sIHdoZXJlIHRoZSBDT1JTIHJlc3BvbnNlIGhlYWRlciAmcXVv dDtBY2Nlc3MtQ29udHJvbC1BbGxvdy1PcmlnaW46IComcXVvdDsgaXMgbWFuZGF0ZWQsIHBlcg0K PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtYXBwc2F3Zy13 ZWJmaW5nZXItMDMjc2VjdGlvbi03IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1hcHBzYXdnLXdlYmZpbmdlci0wMyNzZWN0aW9uLTc8L2E+ LiAmbmJzcDtUaGUgcHJpdmFjeSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlc2UgYXBwcm9hY2hlcyBh cmUgdmVyeSBkaWZmZXJlbnQuICZuYnNwOyhJdCdzIHRoZXNlIHZlcnkgc2FtZSBwcml2YWN5IGNo YXJhY3RlcmlzdGljcyB0aGF0IGxlZCBzeXNhZG1pbnMgdG8gbmVhcmx5IHViaXF1aXRvdXNseSBk aXNhYmxpbmcgdGhlIGZpbmdlcmQgc2VydmljZSEpDQogJm5ic3A7UGFydGljdWxhcmx5IGZvciB0 aGUgT0F1dGggdXNlIGNhc2VzLCBuYXJyb3csIHNjb3BlZCwgYW5kIHBvdGVudGlhbGx5IHBlcm1p c3Npb25lZCByZXNwb25zZXMgc2VlbSBwcmVmZXJhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBhYnNvbHV0ZWx5 IGZhbHNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TV0QgcHJvdmlkZXMgbm8gcHJpdmFjeSB3aGF0c29ldmVyLiBTV0QgbWFrZXMgaXQgc29t ZXdoYXQgaGFyZGVyIHRvIGNyYXdsIGxhcmdlIG51bWJlcnMgb2YgcHJvZmlsZXMsIGJ1dCBpdCBk b2VzIG5vdCBpbmNvcnBvcmF0ZSBhbnkgcmVhbCBzZWN1cml0eSwgYW5kIGFueSBhdHRlbXB0IHRv IHN1Z2dlc3QgdGhhdCBpdCBkb2VzIGlzIG1pc2xlYWRpbmcgYW5kIGRlY2VwdGl2ZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2ViZmluZ2Vy LCBsaWtlIGFueSBnb29kIEhUVFAgc2VydmljZSwgaXMgZGVzaWduZWQgdG8gYWxsb3cgYWNjZXNz IGNvbnRyb2wgdXNpbmcgYXBwcm9wcmlhdGUgbWVhbnMuIFRoYXQgYWNjZXNzIGNvbnRyb2wgc2hv dWxkIG5vdCBiZSAqYm91bmQqIHRvIHRoZSBwcm90b2NvbCwgaW4gdGhlIHNhbWUgd2F5IHRoYXQg SFRUUCBkb2VzIG5vdCBoYXZlIGFueSBSRVFVSVJFRCBhY2Nlc3MgY29udHJvbCBtZWNoYW5pc21z LA0KIHNpbmNlIGRvaW5nIHNvIHdvdWxkIHNldmVyZWx5IHJlc3RyaWN0IGZ1dHVyZSB1c2FnZSBv ZiBhIGNvcmUgcHJvdG9jb2wuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZVRCBoYXMgbm8gcGxhY2UgaW4gYSBkaXNjdXNzaW9uIG9mIHRoZSB0 ZWNobmljYWwgYW5kIHNvY2lhbCBtZXJpdHMgb2YgYSBwcm90b2NvbC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHdoYXQgaXQncyB3b3J0 aCwgbXkgaW50ZW50IHdpdGggd2ViZmluZ2VyICpmcm9tIGRheSBvbmUsIG5lYXJseSBmb3VyIHll YXJzIGFnbyosIGhhcyBiZWVuIHRvIHByb3ZpZGUgcGVybWlzc2lvbmVkIHByb2ZpbGUgZGF0YSAq dXNpbmcgRVhJU1RJTkcqIChvciBuZXcsIHdoZXJlIGFwcHJvcHJpYXRlIG9yIG5lY2Vzc2FyeSwg YmFzZWQgb24gKnJ1bm5pbmcgY29kZSBhbmQgZGVwbG95bWVudCBFWFBFUklFTkNFKikNCiBhY2Nl c3MgY29udHJvbCBtZWNoYW5pc21zIGZvciBwcm9maWxlIGRhdGEuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpZGVhIHRoYXQgdGhlcmUg aXMgT05FIHZpZXcgb2YgdGhlIGRhdGEgaXMgcGF0ZW50bHkgZmFsc2UuIEZvciBleGFtcGxlLCBk ZXBlbmRpbmcgb24gd2hvIGlzIHJlcXVlc3RpbmcgbXkgcHJvZmlsZSBkYXRhLCBJIG1pZ2h0IHJl dHVybiBkaWZmZXJlbnQgY29udGFjdCB0ZWxlcGhvbmUgbnVtYmVycywgYW5kIHRoaXMgYmVoYXZp b3VyIGlzIGNvbXBsZXRlbHkgZmVhc2libGUgdXNpbmcgd2ViZmluZ2VyLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ET0NVTUVOVCBW RVJTVVMgQVBJIE1PREVMLCBERVBMT1lBQklMSVRZLCBBTkQgU0VDVVJJVFk6ICZuYnNwO1dlYkZp bmdlciBpcyBidWlsdCBvbiBhICZxdW90O2RvY3VtZW50IG1vZGVsJnF1b3Q7LCB3aGVyZSBhIHNp bmdsZSBkb2N1bWVudCBpcyByZXR1cm5lZCB0aGF0IGNvbnRhaW5zIG11bHRpcGxlIHJlc291cmNl cyBmb3IgYSBwcmluY2lwYWwuICZuYnNwO1NXRCBpcyBidWlsdCBvbiBhbiAmcXVvdDtBUEkgbW9k ZWwmcXVvdDssIHdoZXJlIHRoZSBsb2NhdGlvbihzKQ0KIG9mIGEgcGFydGljdWxhciByZXNvdXJj ZSBmb3IgYSBwcmluY2lwYWwgYXJlIHJldHVybmVkLiAmbmJzcDtUaGUgcHJvYmxlbSB3aXRoIHRo ZSBkb2N1bWVudCBtb2RlbCBpcyB0aGF0IGRpZmZlcmVudCBwYXJ0aWVzIG9yIHNlcnZpY2VzIG1h eSBiZSBhdXRob3JpdGF0aXZlIGZvciBkaWZmZXJlbnQgcmVzb3VyY2VzIGZvciBhIGdpdmVuIHBy aW5jaXBhbCwgYW5kIHlldCBhbGwgbmVlZCB0aGUgcmlnaHRzIHRvIGVkaXQgdGhlIHJlc3VsdGlu ZyBkb2N1bWVudC4NCiAmbmJzcDtUaGlzIGh1cnRzIGRlcGxveWFiaWxpdHksIGJlY2F1c2UgZG9j dW1lbnQgZWRpdHMgdGhlbiBuZWVkIHRvIGJlIGNvb3JkaW5hdGVkIGFtb25nIHBhcnRpZXMgdGhh dCBtYXkgaGF2ZSBkaWZmZXJlbnQgcmlnaHRzIGFuZCByZXNwb25zaWJpbGl0aWVzLCBhbmQgbWF5 IGhhdmUgbmVnYXRpdmUgc2VjdXJpdHkgaW1wbGljYXRpb25zIGFzIHdlbGwuICZuYnNwOyhKdXN0 IGJlY2F1c2UgSSBjYW4gY2hhbmdlIHlvdXIgYXZhdGFyIGRvZXNuJ3QgbWVhbiB0aGF0DQogSSBz aG91bGQgYmUgYWJsZSB0byBjaGFuZ2UgeW91ciBtYWlsIHNlcnZlci4pPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XUy0qIHdhcyBi dWlsdCBvbiBhbiBBUEkgbW9kZWwsIGFuZCB0aGF0IHdvcmtlZCBvdXQgdmVyeSB3ZWxsLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BUElzIGFu ZCBkb2N1bWVudHMgb24gdGhlIHdlYiBhcmUgdGhlIHNhbWUgdGhpbmc7IGhvdyB5b3UgcmVwcmVz ZW50IHRoZW0gYmVoaW5kIHRoZSBzY2VuZXMgaXMgdXAgdG8geW91LCBhbmQgdGhhdCdzIGJlZW4g YSBjb3JlIHByaW5jaXBsZSBvZiB0aGUgd2ViIHNpbmNlIHNob3J0bHkgYWZ0ZXIgaXRzIGluY2Vw dGlvbi4gU3VnZ2VzdGluZyBvdGhlcndpc2UgcHJvZm91bmRseSBtaXN1bmRlcnN0YW5kcyBob3cg aW1wbGVtZW50YXRpb24NCiBvZiB3ZWIgc2VydmljZXMgaGFwcGVucy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U1dEIHNheXMgbm90aGluZyBv ZiBob3cgdG8gdXBkYXRlIHByb2ZpbGUgZGF0YSwgc28gdGhlIHNlY3VyaXR5IGNvbmNlcm5zIGhl cmUgYXJlIGEgdG90YWwgcmVkIGhlcnJpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJFRElSRUNUIEZVTkNUSU9OQUxJVFkgQU5E IERFUExPWUFCSUxUWTogJm5ic3A7U1dEIGluY2x1ZGVzIHRoZSBhYmlsaXR5IHRvIHJlZGlyZWN0 IHNvbWUgb3IgYWxsIFNXRCByZXF1ZXN0cyB0byBhbm90aGVyIGxvY2F0aW9uIChwb3NzaWJseSBk ZXBlbmRpbmcgdXBvbiB0aGUgc3BlY2lmaWMgcmVzb3VyY2UgYW5kIHByaW5jaXBhbCBwYXJhbWV0 ZXJzKS4gJm5ic3A7RGVwbG95ZXJzIGhvc3RpbmcgbnVtZXJvdXMgc2l0ZXMgZm9yDQogb3RoZXJz IHRvbGQgdGhlIFNXRCBhdXRob3JzIHRoYXQgdGhpcyBmdW5jdGlvbmFsaXR5IGlzIGNyaXRpY2Fs IGZvciBkZXBsb3lhYmlsaXR5LCBhcyBpdCBtZWFucyB0aGF0IHRoZSBTV0Qgc2VydmVyIGZvciBh IGRvbWFpbiBjYW4gbGl2ZSBpbiBhIGxvY2F0aW9uIG91dHNpZGUgdGhlIGRvbWFpbi4gJm5ic3A7 V2ViRmluZ2VyIGlzIGxhY2tpbmcgdGhpcyBmdW5jdGlvbmFsaXR5LiAmbmJzcDtHaXZlbiB0aGF0 IE9BdXRoIGlzIGxpa2VseSB0byBiZSB1c2VkIGluIGhvc3RlZA0KIGVudmlyb25tZW50cywgdGhp cyBmdW5jdGlvbmFsaXR5IHNlZW1zIHByZXR0eSBpbXBvcnRhbnQuPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VbW0sIEknbSBub3Qg ZXZlbiBzdXJlIHdoYXQgdG8gc2F5IHRvIHRoaXMuIGhvc3QtbWV0YSBpcyBhIHN0YXRpYyBmaWxl IHRoYXQgcG9pbnRzIHRvIGEgcHJvZmlsZSBzZXJ2ZXIgKGdlbmVyYWxseSBleHBlY3RlZCB0byBi ZSBhIGR5bmFtaWMgJnF1b3Q7QVBJJnF1b3Q7IHNlcnZlcikgdGhhdCBjYW4gYmUgaG9zdGVkIG9u IGFueSBkb21haW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBmYWN0IHRoYXQgeW91J3JlIHN1Z2dlc3RpbmcgdGhhdCB0aGlzIGNvcmUg cGllY2Ugb2Ygd2ViZmluZ2VyIGZ1bmN0aW9uYWxpdHkgaXMgKm1pc3NpbmcqIHNlcmlvdXNseSB1 bmRlcm1pbmVzIG15IGJlbGllZiB0aGF0IHlvdSdyZSBhY3RpbmcgaW4gZ29vZCBmYWl0aCwgTWlr ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TlVNQkVSIE9GIFJPVU5EIFRSSVBTOiAmbmJzcDtXZWJGaW5nZXIgZGlzY292ZXJpZXMg Zm9yIHVzZXIgaW5mb3JtYXRpb24gbm9ybWFsbHkgcmVxdWlyZSBib3RoIGEgaG9zdC1tZXRhIHF1 ZXJ5IHRvIHJldHJpZXZlIHRoZSB0ZW1wbGF0ZSBhbmQgdGhlbiBhIHNlY29uZCBxdWVyeSB0byBy ZXRyaWV2ZSB0aGUgdXNlcidzIGluZm9ybWF0aW9uLiAmbmJzcDtUaGlzIGZ1bmN0aW9uYWxpdHkg aXMgYWNoaWV2ZWQgaW4gYSBzaW5nbGUNCiBTV0QgcXVlcnkuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4uLi4gYXQgdGhlIGNvc3Qg b2YgZ3JlYXRlciBjbGllbnQgY29tcGxleGl0eS4gQSB3ZWJmaW5nZXIgbG9va3VwIG1heSBiZSBp bXBsZW1lbnRlZCB3aXRoIHRoZSBmb2xsb3dpbmcgdHJpdmlhbCBzaGVsbCBzY3JpcHQ6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Y3VybCAtcyA8YSBocmVm PSJodHRwOi8vZXhhbXBsZS5jb20vLndlbGwta25vd24vaG9zdC1tZXRhfGF3ayI+DQpodHRwOi8v ZXhhbXBsZS5jb20vLndlbGwta25vd24vaG9zdC1tZXRhfGF3azwvYT4gJnF1b3Q7L2xyZGQvLC90 ZW1wbGF0ZS8mcXVvdDt8dHIgLWQgJ1xuJ3xzZWQgLWUgJnF1b3Q7cy9eLip0ZW1wbGF0ZT0nXChb XiddKlwpJy4qJC9cMS8mcXVvdDt8c2VkIC1lICZxdW90O3Mve3VyaX0vPGEgaHJlZj0iaHR0cDov L3VzZXJAZXhhbXBsZS5jb20vIj51c2VyQGV4YW1wbGUuY29tLzwvYT4mcXVvdDt8eGFyZ3MgY3Vy bCAtczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+c28gbG9uZyBhcyB5b3VyIEhUVFAgY2xpZW50IHByb3Blcmx5IGZvbGxvd3MgcmVk aXJlY3RzLCB0aGlzIGFwcHJvYWNoIHdpbGwgYWx3YXlzIHByb2R1Y2UgYSB2YWxpZCB3ZWJmaW5n ZXIgcHJvZmlsZSwgYW5kIGlmIHByb3BlciBjYWNoaW5nIGlzIGltcGxlbWVudGVkLCB3aWxsIG9u bHkgbWFrZSByZXF1ZXN0cyB0byAvLndlbGwta25vd24vaG9zdC1tZXRhIHdoZW4gdGhlIGRvY3Vt ZW50IGlzIGV4cGlyZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNXRCwgb24gdGhlIG90aGVyIGhhbmQsIGltcGxlbWVudHMgYSBub24tSFRU UCByZWRpcmVjdCBtZWNoYW5pc20sIG1lYW5pbmcgdGhhdCBvcHRpbWFsIGNhY2hpbmcgcnVsZXMg Y2FuJ3QgYmUgb2JleWVkIGJ5IHN0YW5kYXJkIEhUVFAgY2xpZW50cy4gTW9yZW92ZXIsIFNXRCAq cmVxdWlyZXMqIGNvbmRpdGlvbmFscyBieSBwcmVzZW50aW5nIG9uZSBjb2RlIHBhdGggZm9yIHRo ZSBub24tcmVkaXJlY3QgY2FzZSBhbmQNCiBvbmUgY29kZSBwYXRoIGZvciB0aGUgaW1tZWRpYXRl IHJlc3BvbnNlIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBjb21wbGV4aXR5IGZvciBjbGllbnQgaW1wbGVtZW50YXRpb25zIHNo b3VsZCBiZSBmb3JlbW9zdCBpbiB0aGlzIHdvcmssIGFuZCB0aGUgZGVjaXNpb25zIG1hZGUgYnkg U1dEIGRvbid0IGluZGljYXRlIHRvIG1lIHRoYXQgdGhlc2UgZmFjdG9ycyBoYXZlIGJlZW4gY29u c2lkZXJlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SW5kZWVkLCBJIHdvbmRlciB3aHkmbmJzcDtpcyBTV0QgZGVzaWduZWQgdG8gcHJlLW9w dGltaXplIGZvciBwcmVzdW1lZCBzY2FsaW5nIGNoYWxsZW5nZXMgdGhhdCBhcmUgZmFjZWQgYnkg b25seSB0aGUgdmVyeSBsYXJnZXN0IHByb3ZpZGVycyAobmFtZWx5LCB0aGUgZmFjdCB0aGF0IHR3 byBsb29rdXBzIGFyZSByZXF1aXJlZCBmb3Igd2ViZmluZ2VyIGluc3RlYWQgb2Ygb25lIGluIHRo ZSBpZGVhbCBjYXNlKSwgd2hlbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+MS4gVGhvc2Ugc2NhbGluZyBjaGFsbGVuZ2VzIGFyZSBzaW1wbHkg bm90IHJlYWwgdGhyZWF0cy4gaG9zdC1tZXRhIGNhbiBiZSBjYWNoZWQgdXNpbmcgZXhpc3Rpbmcg SFRUUCBtZWNoYW5pc21zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4yLiBUaGUgZmFjdCB0aGF0IFNXRCBvbmx5IHJldHVybnMgb25lIHNlcnZpY2Ug ZGVmaW5pdGlvbiBwZXIgcmVxdWVzdCBtZWFucyB0aGF0IG1vcmUgdGhhbiBvbmUgcmVxdWVzdCB3 aWxsIG9mdGVuIGJlIHJlcXVpcmVkIHRvIG9idGFpbiB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0aW9u IGFib3V0IGEgdXNlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjMuIFRoZSBjaGFuY2VzIHRoYXQgR29vZ2xlIG9yIE1pY3Jvc29mdCB3aWxsIGhv c3QgZHluYW1pYyByZXNwb25zZSBTV0Qgc2VydmljZXMgb24gdGhlDQo8YSBocmVmPSJodHRwOi8v Z21haWwuY29tIj5nbWFpbC5jb208L2E+IG9yIDxhIGhyZWY9Imh0dHA6Ly9ob3RtYWlsLmNvbSI+ aG90bWFpbC5jb208L2E+IGRvbWFpbnMgaXMgbmV4dCB0byBuaWwsIGFuZCB3aWxsIHRoZXJlZm9y ZSBuZWVkIHRvIGlzc3VlIHJlZGlyZWN0cyBhbnl3YXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3Igc21hbGxlciBwcm92aWRlcnMgKGUu Zy4sIHBlcnNvbmFsIGRvbWFpbnMgaG9zdGVkIGluIHN0YXRpYyBvciByaWdpZCBlbnZpcm9ubWVu dHMpLCBob3N0aW5nIGEgU1dEIHNlcnZlciBhdCAvLndlbGwta25vd24vc2ltcGxlLXdlYi1kaXNj b3ZlcnkgbWF5IGJlIGNoYWxsZW5naW5nIGluZGVlZC4gVGh1cywgYWxsIGNsaWVudHMgd2lsbCBu ZWVkIHRvIHN1cHBvcnQgdGhlIHJlZGlyZWN0IGJlaGF2aW91ciBuYXRpdmVseSwNCiBhbmQgZm9y IHRob3NlIHdobyB3cml0ZSBzcGVjcyBidXQgbm90IGNvZGUsIGl0IGlzICptb3JlKiBjb21wbGV4 IHRvIGhhdmUgY29uZGl0aW9uYWwgYmVoYXZpb3VyIGxpa2UgdGhhdCB0aGFuIHRvIGhhdmUgYSBk ZWZpbmVkIGZsb3cgdGhhdCBpcyBhbHdheXMgZm9sbG93ZWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZ1cnRoZXIsIGl0J3MgbW9yZSBjb21w bGV4IGZvciBzbWFsbCBzZXJ2aWNlIHByb3ZpZGVycyB0byBob3N0IHN0YXRpYyBjb250ZW50IHRo YXQgaXMgaW52YXJpYW50IGFuZCBwcm9wZXJseSBjYWNoZWQgKGUuZy4sIGJ5IHRyYW5zcGFyZW50 IHByb3h5IGNhY2hlcyBsaWtlIHZhcm5pc2ggYW5kIHNxdWlkKSB3aGVuIENHSSBwYXJhbWV0ZXJz IGFyZSBhcHBlbmRlZCwgYXMgd2l0aCBTV0QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlhNTCBBTkQgSlNPTiBWRVJTVVMgSlNPTjog Jm5ic3A7V2ViRmluZ2VyIHNwZWNpZmllcyBib3RoIFhNTCBhbmQgSlNPTiBzdXBwb3J0LCB3aGVy ZWFzIFNXRCBzcGVjaWZpZXMgb25seSBKU09OLiAmbmJzcDtUaGUgU1dEIHBvc2l0aW9uIGlzIHRo YXQgaXQncyBzaW1wbGVyIHRvIHNwZWNpZnkgb25seSBvbmUgd2F5IG9mIGRvaW5nIHRoZSBzYW1l IHRoaW5nLCB3aXRoIEpTT04gYmVpbmcgY2hvc2VuIGJlY2F1c2UgaXQncyBzaW1wbGVyDQogZm9y IGRldmVsb3BlcnMgdG8gdXNlIHRoYW4gWE1MIC0gdGhlIHNhbWUgZGVjaXNpb24gYXMgbWFkZSBm b3IgdGhlIE9BdXRoIHNwZWNzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2ViZmluZ2VyIG9ubHkgdXNlZCBYUkQgaW4gdGhlIGZp cnN0IHBsYWNlIHRvIHNhdGlzZnkgdGhlIE9wZW5JRCBjb21tdW5pdHkuIFRoaXMgaXMgaW5mdXJp YXRpbmcgZm9ybWF0LWZldGlzaGlzbSwgYW5kIG1pc3NlcyB0aGUgcG9pbnQgZW50aXJlbHkuIEpT T04gaXMgcHJlZmVycmVkLCBhbmQgSSwgZm9yIG9uZSwgd291bGQgaGFwcGlseSBtb2RpZnkgaG9z dC1tZXRhIGFuZCB3ZWJmaW5nZXIgdG8gcmVxdWlyZQ0KIEpTT04gaXMgcGVvcGxlIGZlZWwgdGhp cyBzdHJvbmdseSBhYm91dCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+REVGSU5JTkcgU1BFQ0lGSUMgUkVTT1VSQ0VTOiAmbmJz cDtCZXNpZGVzIHNwZWNpZnlpbmcgYSBkaXNjb3ZlcnkgcHJvdG9jb2wsIFdlYkZpbmdlciBhbHNv IGRlZmluZXMgc3BlY2lmaWMgcmVzb3VyY2VzIGFuZCBraW5kcyBvZiByZXNvdXJjZXMgdG8gYmUg dXNlZCB3aXRoIHRoYXQgcHJvdG9jb2w6ICZuYnNwO3RoZSAmcXVvdDthY2N0JnF1b3Q7IFVSSSBz Y2hlbWUsIHRoZSAmcXVvdDthY2N0JnF1b3Q7IExpbmsgUmVsYXRpb24uICZuYnNwO1RoZXNlIHNo b3VsZCBiZSBjb25zaWRlcmVkDQogb24gdGhlaXIgb3duIG1lcml0cywgYnV0IGxvZ2ljYWxseSBz aG91bGQgYmUgZGVjb3VwbGVkIGZyb20gdGhlIGRpc2NvdmVyeSBwcm90b2NvbCBpbnRvIGEgZGlm ZmVyZW50IGRvY3VtZW50IG9yIGRvY3VtZW50cy4gJm5ic3A7SXQncyBub3QgY2xlYXIgdGhlc2Ug ZmVhdHVyZXMgd291bGQgYmUgbmVlZGVkIGluIE9BdXRoIGNvbnRleHRzLjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGxv bmcgYXJndWVkIGFnYWluc3QgdGhlIGFjY3QgVVJJLCBidXQgdGhlIGNvbnNlbnN1cy1iYXNlZCBh cHByb2FjaCBvZiB0aGUgSUVURiBoYXMgb3Zlci1yaWRkZW4gbWUgb24gdGhhdCBvbmUuIElmIHlv dSBmZWVsIHNpbWlsYXJseSwgeW91IGFyZSBmcmVlIHRvIHZvaWNlIHRoYXQgb3Bpbmlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2hv Y2tzIG1lIHRoYXQgeW91J3JlIHNheWluZyB0aGF0IHRoZSBPQXV0aCBXRyBzaG91bGRuJ3QgY29u c2lkZXIgaG9zdC1tZXRhL3dlYmZpbmdlciBiZWNhdXNlIGl0IGRlZmluZXMgc29tZXRoaW5nIHRo YXQgaXNuJ3Qgb2YgaW50ZXJlc3QgdG8gdGhlIE9BdXRoIFdHLiBUaGUgd2hvbGUgcG9pbnQgb2Yg bXkgYXJndW1lbnQgYXQgdGhlIFdHIG1lZXRpbmcgaW4gUGFyaXMgd2FzIHRoYXQgV2ViZmluZ2Vy IGFuZA0KIFNXRC1saWtlIHByb3RvY29scyBhcmUgb2Ygc3VjaCBjb25zZXF1ZW5jZSB0byB0aGUg d2ViIGF0IGxhcmdlIHRoYXQgdGhlIGludGVyZXN0cyBvZiB0aGUgT0F1dGggV0cgc2hvdWxkIG5v dCBiZSB1c2VkIHRvIGRlZmluZSB0aGUgcGFyYW1ldGVycyBmb3IgdGhlaXIgYmVoYXZpb3VyLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20g bW9yZSBjb252aW5jZWQgdGhhdCB5b3UncmUgdXNpbmcgeW91ciBwb3dlciB3aXRoaW4gdGhpcyBX RyB0byBoYXZlIFNXRCBydWJiZXItc3RhbXBlZCBzbyB0aGF0IHlvdSBjYW4gc2hpcCBPcGVuSUQg Q29ubmVjdCBhcyB5b3UndmUgZGVmaW5lZCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UVVFU1RJT05TPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQoxKSBBcmVuJ3QgdGhlc2UgdHdvIG1lY2hhbmlzbXMgc29sdmluZyBwcmV0dHkgbXVj aCB0aGUgc2FtZSBwcm9ibGVtPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg VGhleSBhcmUgc29sdmluZyBhbiBvdmVybGFwcGluZyBzZXQgb2YgcHJvYmxlbXMsIGJ1dCB3aXRo IHZlcnkgZGlmZmVyZW50IHByaXZhY3kgY2hhcmFjdGVyaXN0aWNzLCBkaWZmZXJlbnQgZGVwbG95 YWJpbGl0eSBjaGFyYWN0ZXJpc3RpY3MsIGRpZmZlcmVudCBzZWN1cml0eSBjaGFyYWN0ZXJpc3Rp Y3MsIGFuZCBzb21ld2hhdCBkaWZmZXJlbnQgbWVjaGFuaXNtcy48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFnYWluLCBJIHRvdGFs bHkgZGlzYWdyZWUgd2l0aCB5b3VyIGFzc2Vzc21lbnQgaGVyZSwgTWlrZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+MikgRG8gd2UgbmVlZCB0byBoYXZlIHR3byBzdGFu ZGFyZHMgZm9yIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBObyAtIFNpbXBsZSBXZWIgRGlzY292ZXJ5IGlzIHN1ZmZpY2llbnQgZm9y IHRoZSBPQXV0aCB1c2UgY2FzZXMgKGFuZCBsaWtlbHkgZm9yIG90aGVycyBhcyB3ZWxsKS48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgYWdyZWUgd2l0aCB0aGlzIOKAkyBzaW5jZSBTV0QgaXMgYW4gZXhwbGljaXQgKHRob3VnaCB1 bnN0YXRlZCkgZm9yayBvZiBXZWJmaW5nZXIsIHRoZXJlIGlzIG5vIG5lZWQgdG8gaGF2ZSB0d28g c3RhbmRhcmRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4zKSBEbyB5 b3UgZ3V5cyBoYXZlIGEgcG9zaXRpb24gb3IgY29tbWVudHMgcmVnYXJkaW5nIGVpdGhlciBvbmUg b2YgdGhlbT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBmdW5jdGlv bmFsaXR5IGluIFNpbXBsZSBXZWIgRGlzY292ZXJ5IGlzIG1pbmltYWwgYW5kIHN1ZmZpY2llbnQg Zm9yIHRoZSBPQXV0aCB1c2UgY2FzZXMsIHdoZXJlYXMgc29tZSBvZiB0aGUgZnVuY3Rpb25hbGl0 eSBhbmQgYXNzdW1wdGlvbnMgbWFkZSBpbiBXZWJGaW5nZXIgYXJlIGhhcm1mdWwsIGJvdGggZnJv bSBhIHByaXZhY3kgYW5kIGZyb20gYSBkZXBsb3lhYmlsaXR5IHBlcnNwZWN0aXZlLg0KICZuYnNw O1NXRCBzaG91bGQgcHJvY2VlZCB0byBzdGFuZGFyZGl6YXRpb247IFdlYkZpbmdlciBzaG91bGQg bm90LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBiZWxpZXZlIE1pa2UgaGFzIG1hZGUgbWlzbGVhZGluZyBzdGF0ZW1lbnRzIHJl Z2FyZGluZyB0aGUgcHJpdmFjeSBhbmQgZGVwbG95YWJpbGl0eSBwZXJzcGVjdGl2ZSwgZWl0aGVy IGludGVudGlvbmFsbHksIG9yIGJlY2F1c2UgaGUgZnVuZGFtZW50YWxseSBkb2VzIG5vdCB1bmRl cnN0YW5kIHRoZSBzZWN1cml0eSBvciBkZXBsb3ltZW50IHNjZW5hcmlvcyB0aGF0IG1vdGl2YXRl IHRoZSBkZWNpc2lvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkluIHN1bW1hcnk6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIEkgYmVsaWV2ZSB0aGF0IFNXRCBhbmQgV2ViZmluZ2Vy IGFyZSBlc3NlbnRpYWxseSB0aGUgc2FtZSBwcm90b2NvbCwgd2l0aCBkaWZmZXJlbnQgYXV0aG9y cyBuYW1lcyBhdCB0aGUgdG9wLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Mi4gSSBkb24ndCBjYXJlIHdoaWNoIG9uZSAmcXVvdDt3aW5zJnF1b3Q7 LCB0aG91Z2ggSSB0aGluayB0aGF0IFNXRCdzIHVzZSBvZiBIVFRQIGlzIHF1ZXN0aW9uYWJsZSwg YW5kIHRoYXQgdGhlIGNsYWltcyBvZiBwcml2YWN5IGFuZCBkZXBsb3lhYmlsaXR5IGFkdmFudGFn ZXMgb2ZmZXJlZCBieSBTV0QgYXJlIG92ZXJibG93biBhbmQgcG90ZW50aWFsbHkgbWlzbGVhZGlu Zy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMu IE15IGNvbmNlcm5zIGFib3V0IFNXRCBhcHBseSBlcXVhbGx5IHRvIGFueSBjb25jZXJucyBhbnlv bmUgd291bGQgbGV2ZXJhZ2UgYWdhaW5zdCBXZWJmaW5nZXIuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiBXaGljaCBpcyB0byBzYXksIEkgdGhp bmsgd2Ugc2hvdWxkIGhhdmUgb25lIHByb3RvY29sIHRoYXQgaXMgZGVmaW5lZCBieSBhbiBvcGVu IGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj41LiBXZSd2ZSBoYWQgYW4gb3BlbiBkaXNjdXNzaW9uIG9uIHRoZSB3ZWJmaW5nZXIg bGlzdCBhbmQgYXBwcy1kaXNjdXNzIGFuZCBpbiB0aGUgY29udGV4dCBvZiBob3N0LW1ldGEgdGhh dCB0aGUgU1dEIGZvbGtzIGhhdmUgY2hvc2VuIG5vdCB0byBlbmdhZ2Ugd2l0aCBmb3IgdGhlIHBh c3QgdGhyZWUgeWVhcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj42LiBUaGUgT0F1dGggbGlzdCBpcyAqbm90KiB0aGUgcGxhY2UgZm9yIHRoaXMg ZGlzY3Vzc2lvbiB0byBoYXBwZW4sIGp1c3Qgc28gdGhhdCBNaWtlIEpvbmVzIGNhbiBxdWlja2x5 IHB1c2ggYSBzcGVjIHRocm91Z2ggdGhlIGZvcm1hbCBwcm9jZXNzIHVzaW5nIGEgbGlzdCB0aGF0 IGhhcyB3ZWxsLWtub3duIHByb2JsZW1zIG9mIHRvby1oaWdoIG1haWwgdm9sdW1lIGFuZCB3aG9z ZSB0b3BpYyBpcyB1bnJlbGF0ZWQNCiB0byB0aGUgZ29hbHMgb2YgV2ViZmluZ2VyL1NXRC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBp cyBpbXBvcnRhbnQgZW5vdWdoIHRvIGdldCByaWdodCwgYW5kIGdldHRpbmcgaXQgd3Jvbmcgd2ls bCBhbG1vc3QgY2VydGFpbmx5IGxlYWQgdG8geWVhcnMgb2YgaW5jb21wYXRpYmlsaXR5IGFuZCBm cnVzdHJhdGlvbiwgYXMgU3RlcGhlbiBtZW50aW9uZWQuIEkgZW5jb3VyYWdlIGV2ZXJ5b25lIGlu dm9sdmVkIHRvIHRha2UgdGhpcyBzZXJpb3VzbHksIGxldCBnbyBvZiBwZXJzb25hbCBhdHRhY2ht ZW50DQogYW5kIHByZXN1bXB0aW9ucyBvZiBkZXBlbmRlbmNpZXMsIGFuZCBjb25zaWRlciB0aGlz IHdvcmsgaW4gYW4gYXBwcm9wcmlhdGUgY29udGV4dCAod2l0aCBhbiBpbmNsdXNpdmUsIG5vdCBl eGNsdXNpdmUgY29tbXVuaXR5KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Yi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739436646671BTK5EX14MBXC283r_-- From stephen.farrell@cs.tcd.ie Fri Apr 13 09:22:46 2012 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 1F47221F867A; Fri, 13 Apr 2012 09:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBgl92suJQZS; Fri, 13 Apr 2012 09:22:45 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 23B0921F8675; Fri, 13 Apr 2012 09:22:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6410217147A; Fri, 13 Apr 2012 17:22:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334334164; bh=W1oxmRoO9QeZoe EXt7ex2zKBC+zTIb+cDNEEcEWNDpo=; b=tkE3QvnZfaJn9KAIHcz6G6QicT5BBg p0eqcaHcNhwkcdIfduuR+oIBbK5AR2QKSJ+QlzXdcpM2ThrruDS9Mlvxdn0AL6BG JtRK0uVSHQKdb62x9OPCWdEMAZnP8EGwFeiND23U4/1oOhhY8KvooYxdRPUCo4ny EIMdXCufoDFkhiA9Rs103FcLojZMMVARrRhkvBPVdG/GUvnps9Wwv/tavdKlGdOY m+WO6To0whOVgR92pQZJ0u6zynweseF7nzFsnv6yT2l+heCdOK6yzAiDidn4l9jJ XoramisPSQ3THFXlMoRVAkpYCoqbNNKGRXn3YiNCctH4uMi8C4bFScVQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Rce+sZwfP0o7; Fri, 13 Apr 2012 17:22:44 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DD3A7171479; Fri, 13 Apr 2012 17:22:43 +0100 (IST) Message-ID: <4F8852D0.4020404@cs.tcd.ie> Date: Fri, 13 Apr 2012 17:22:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "oauth@ietf.org WG" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> In-Reply-To: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 13 Apr 2012 16:22:46 -0000 Hi All, So Hannes and Derek and I have been discussing this with the Apps ADs and Apps-area WG chairs. I've also read the docs now, and after all that we've decided that this topic (what to do with swd and webfinger) is best handled in the apps area and not in the oauth WG. The logic for that is that 1) the two proposals are doing the same thing and we don't want two different standards for that, b) this is not an oauth-specific thing nor is it a general security thing, and c) there is clearly already interest in the topic in the apps area so its reasonable for the oauth wg to use that when its ready. The appsawg chairs and apps ADs are ok with the work being done there. So:- - I've asked the oauth chairs to take doing work on swd out of the proposed new charter - It may be that you want to add something saying that oauth will use the results of work in the applications area on a web discovery protocol as a basis for doing the dynamic client registration work here - Discussion of webfinger and swd should move over to the apps-discuss list - Note: this is not picking one or the other approach, the plan is that the apps area will do any selection needed and figure out the best starting point for a standards-track RFC on web discovery and we'll use their fine work for doing more with oauth. Regards, Stephen. On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: > Hi all, > > those who had attended the last IETF meeting may have noticed the ongoing activity in the 'Applications Area Working Group' regarding Web Finger. > We had our discussion regarding Simple Web Discovery (SWD) as part of the re-chartering process. > > Here are the two specifications: > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 > > Now, the questions that seems to be hanging around are > > 1) Aren't these two mechanisms solving pretty much the same problem? > 2) Do we need to have two standards for the same functionality? > 3) Do you guys have a position or comments regarding either one of them? > > Ciao > Hannes > > PS: Please also let me know if your view is: "I don't really know what all this is about and the documents actually don't provide enough requirements to make a reasonable judgement about the solution space." > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From melvincarvalho@gmail.com Fri Apr 13 09:31:03 2012 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 5FB1021F87E7 for ; Fri, 13 Apr 2012 09:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkrE8sEtBypS for ; Fri, 13 Apr 2012 09:31:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F89221F87D2 for ; Fri, 13 Apr 2012 09:31:02 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2597618vbb.31 for ; Fri, 13 Apr 2012 09:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qSAIAUOC86Dh4Z3wvCcL2GRfZ+0AUnIFjU+IOUWUE9U=; b=iAq+6rVRGsHwkPpFlQmo/CHalif0iEi51dalWG357F3jxdeNgjU5BP2nkkTs2npxSF nIGh1cTkcE9+Wp6Y5ps2aYt/ETtn4PnTE5TPS4KMEH8Zs8XVr9GNt8HSOuEKsETPK8MF orJwWf3cCtrQUmJqHoQtd8A6lX3leUKnAHFLcHUdF99WbuJIivntsGqmf5/S3CvoGUsB 6jdWxQdqGRQn56JglZZYpr543CclBQ8fmpFrGhcei3ttSQMoqW9nOWfuK8Gcclp4fb9+ g96/uawEkKzK2IKxHz5TJkQzUhhF9BtWSDb3f79Xd8kWVI3fOc+vSZ/H2hLOHgdFFWan iwvQ== MIME-Version: 1.0 Received: by 10.52.240.171 with SMTP id wb11mr846260vdc.106.1334334661960; Fri, 13 Apr 2012 09:31:01 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Fri, 13 Apr 2012 09:31:01 -0700 (PDT) In-Reply-To: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> Date: Fri, 13 Apr 2012 18:31:01 +0200 Message-ID: From: Melvin Carvalho To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=20cf307ca3dc89a41404bd91ff56 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 13 Apr 2012 16:31:03 -0000 --20cf307ca3dc89a41404bd91ff56 Content-Type: text/plain; charset=ISO-8859-1 On 12 April 2012 13:00, Hannes Tschofenig wrote: > Hi all, > > those who had attended the last IETF meeting may have noticed the ongoing > activity in the 'Applications Area Working Group' regarding Web Finger. > We had our discussion regarding Simple Web Discovery (SWD) as part of the > re-chartering process. > > Here are the two specifications: > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 > > Now, the questions that seems to be hanging around are > > 1) Aren't these two mechanisms solving pretty much the same problem? > 2) Do we need to have two standards for the same functionality? > 3) Do you guys have a position or comments regarding either one of them? > No mention of Linked Data? (eg JSON LD). Even tho it's used to discover data by most governments, the world bank, over 2000 retailers, all major search engines? Webfinger I love the concept, but seems overly complicated to me. Introduction of the acct: scheme seems unnecessary. No where in the spec does it cover how to get from mailto:user@host -> acct:user@host which, if im not mistaken, seems to defeat the object of the forward lookup. From a practical perspective it seems both xml and json must be supported which is an added layer of complexity. Also note that discovery is an additive process... in a certain way, you could say, the more the better :) > > Ciao > Hannes > > PS: Please also let me know if your view is: "I don't really know what all > this is about and the documents actually don't provide enough requirements > to make a reasonable judgement about the solution space." > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --20cf307ca3dc89a41404bd91ff56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 12 April 2012 13:00, Hannes Tschofeni= g <hannes= .tschofenig@gmx.net> wrote:
Hi all,

those who had attended the last IETF meeting may have noticed the ongoing a= ctivity in the 'Applications Area Working Group' regarding Web Fing= er.
We had our discussion regarding Simple Web Discovery (SWD) as part of the r= e-chartering process.

Here are the two specifications:
http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03<= /a>
http://tools.ietf.org/html/draft-jones-simple-web-discove= ry-02

Now, the questions that seems to be hanging around are

=A01) Aren't these two mechanisms solving pretty much the same problem?=
=A02) Do we need to have two standards for the same functionality?
=A03) Do you guys have a position or comments regarding either one of them?=

No mention of Linked Data?=A0 (eg JSON LD).=A0 Ev= en tho it's used to discover data by most governments, the world bank, = over 2000 retailers, all major search engines?

Webfinger I love the concept, but seems overly complicated to me.=A0 In= troduction of the acct: scheme seems unnecessary.=A0 No where in the spec d= oes it cover how to get from mailto:user@host<= /a> -> acct:user@host which, if im not mistaken, seems to defeat the obj= ect of the forward lookup.=A0 From a practical perspective it seems both xm= l and json must be supported which is an added layer of complexity.

Also note that discovery is an additive process... in a certain way, yo= u could say, the more the better :)
=A0

Ciao
Hannes

PS: Please also let me know if your view is: "I don't really know = what all this is about and the documents actually don't provide enough = requirements to make a reasonable judgement about the solution space."=




_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--20cf307ca3dc89a41404bd91ff56-- From jricher@mitre.org Fri Apr 13 09:39:02 2012 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 19A9711E8075 for ; Fri, 13 Apr 2012 09:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKSaFmJJFcUB for ; Fri, 13 Apr 2012 09:39:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BF01D11E8073 for ; Fri, 13 Apr 2012 09:38:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2110D21B13FD; Fri, 13 Apr 2012 12:38:57 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1404921B13F9; Fri, 13 Apr 2012 12:38:57 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 13 Apr 2012 12:38:56 -0400 Message-ID: <4F885680.5090801@mitre.org> Date: Fri, 13 Apr 2012 12:38:24 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <59E470B10C4630419ED717AC79FCF9A906E74E@CH1PRD0410MB369.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A906E74E@CH1PRD0410MB369.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------090206040803070703090100" X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Fri, 13 Apr 2012 16:39:02 -0000 --------------090206040803070703090100 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit If the mobile device has a web browser (such as a smart phone), then this is pretty easy, and you've got a couple of options. One of the best options when the token is on behalf of an end user is, in my opinion, to use the authorization code flow like this: First, register what's called a "public client" with your server -- so you'll get an ID but not a client secret. With that client ID, register a custom-scheme callback URI, like "myapp://oauthcallback", and register your app on the device as the handler for "myapp". In your application, to start things off, you fire off a web browser to the authorization server's authorization endpoint. The user logs in to the authorization server through the web browser, approves this copy of your app, and gets redirected to "myapp://oauthcallback?code=basdf132". Your app grabs the "myapp://" url and plucks the authorization code off the end of it. Your app then takes that code and sends it in the background to the token endpoint to exchange for a token. Some key points: 1) You need to have access to a web browser on the platform, and it's considered best practice to push the user to the external browser application on the platform instead of embedding one. There are a couple paragraphs in the spec's security considerations section that talk about this. 2) Your app is "public" because you can't publish it with a secret at configuration time. It can, however, keep the tokens secret at runtime. 3) You need to be very careful with how you store the tokens on the device -- they need to be in a trusted space where other apps on the device can't sniff them out. 4) Another app can try to register "myapp://" and intercept your code on the way through, so make sure your codes are all one time use and short lived. None of this is just theoretically possible, people are doing it today. What libraries and stuff you'd be after depends wholly on your platform (both server and client side). -- Justin On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote: > > Hi all, > > I've been talking to some of you off line about this already, but I > need some help in terms of implementation. I would like to use OAuth > as a means to get either a JWT or SAML token to a client running on a > handheld device. This is something that I'm looking to prototype (as > part of a larger project) beginning this week. So, it is important to > me to understand the divide between what is theoretically possible and > what is actually possible. > > Anybody aware of any implementations out there, either vendor or open > source, that I can use for this? > > Tx! > adam > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------090206040803070703090100 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit If the mobile device has a web browser (such as a smart phone), then this is pretty easy, and you've got a couple of options.

One of the best options when the token is on behalf of an end user is, in my opinion, to use the authorization code flow like this: First, register what's called a "public client" with your server -- so you'll get an ID but not a client secret. With that client ID, register a custom-scheme callback URI, like "myapp://oauthcallback", and register your app on the device as the handler for "myapp".

In your application, to start things off, you fire off a web browser to the authorization server's authorization endpoint. The user logs in to the authorization server through the web browser, approves this copy of your app, and gets redirected to "myapp://oauthcallback?code=basdf132". Your app grabs the "myapp://" url and plucks the authorization code off the end of it. Your app then takes that code and sends it in the background to the token endpoint to exchange for a token.

Some key points:

1) You need to have access to a web browser on the platform, and it's considered best practice to push the user to the external browser application on the platform instead of embedding one. There are a couple paragraphs in the spec's security considerations section that talk about this.
2) Your app is "public" because you can't publish it with a secret at configuration time. It can, however, keep the tokens secret at runtime.
3) You need to be very careful with how you store the tokens on the device -- they need to be in a trusted space where other apps on the device can't sniff them out.
4) Another app can try to register "myapp://" and intercept your code on the way through, so make sure your codes are all one time use and short lived.

None of this is just theoretically possible, people are doing it today. What libraries and stuff you'd be after depends wholly on your platform (both server and client side).

 -- Justin

On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote:

Hi all,

 

I’ve been talking to some of you off line about this already, but I need some help in terms of implementation.  I would like to use OAuth as a means to get either a JWT or SAML token to a client running on a handheld device.  This is something that I’m looking to prototype (as part of a larger project) beginning this week.  So, it is important to me to understand the divide between what is theoretically possible and what is actually possible.

 

Anybody aware of any implementations out there, either vendor or open source, that I can use for this?

 

Tx!
adam



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------090206040803070703090100-- From jricher@mitre.org Fri Apr 13 10:02:19 2012 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 DFA4611E8089 for ; Fri, 13 Apr 2012 10:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqNu-vmpHDPs for ; Fri, 13 Apr 2012 10:02:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B098321F842B for ; Fri, 13 Apr 2012 10:02:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5BEFC21B168E; Fri, 13 Apr 2012 13:02:18 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 422F421B0E2C; Fri, 13 Apr 2012 13:02:18 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 13 Apr 2012 13:02:17 -0400 Message-ID: <4F885BF9.2080307@mitre.org> Date: Fri, 13 Apr 2012 13:01:45 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Hannes Tschofenig References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> In-Reply-To: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Fri, 13 Apr 2012 17:02:20 -0000 Did the "Introspection Endpoint" or "Methods for connecting a PR to an AS" get dropped? There seemed to be interest in the list in coming up with a generally applicable scheme, or set of schemes, to do this, and there are certainly no shortage of starting points. Both AOL and Ping have their own token introspection drafts that got put to the list, we've developed our own internal approach here, UMA has an alternative approach, and OpenID Connect has invented its own approach for ID Tokens. I just want to make sure that this was an explicit decision of it being out of scope here and not an inadvertent omission. -- Justin On 04/12/2012 06:55 AM, Hannes Tschofenig wrote: > Hey guys > > based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. > Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): > > ---------- > > > Web Authorization Protocol (oauth) > > Description of Working Group > > The Web Authorization (OAuth) protocol allows a user to grant > a third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that supports > OAuth could allow its users to use a third-party printing Web site to > print their private pictures, without allowing the printing site to > gain full control of the user's account and without having the user > sharing his or her photo-sharing sites' long-term credential with the > printing site. > > The OAuth protocol suite encompasses > * a procedure for allowing a client to discover a resource server, > * a protocol for obtaining authorization tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these authorization tokens to protected > resources for access to a resource, and > * consequently for sharing data in a security and privacy respective way. > > In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, > was published as an informational document (RFC 5849). With the > completion of OAuth 1.0 the working group started their work on OAuth 2.0 > to incorporate implementation experience with version 1.0, additional > use cases, and various other security, readability, and interoperability > improvements. An extensive security analysis was conducted and the result > is available as a stand-alone document offering guidance for audiences > beyond the community of protocol implementers. > > The working group also developed security schemes for presenting authorization > tokens to access a protected resource. This led to the publication of > the bearer token as well as the message authentication code (MAC) access > authentication specification. > > OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with > the SAML 2.0 bearer assertion profile. This offers interworking with existing > identity management solutions, in particular SAML based deployments. > > OAuth has enjoyed widespread adoption by the Internet application service provider > community. To build on this success we aim for nothing more than to make OAuth the > authorization framework of choice for any Internet protocol. Consequently, the > ongoing standardization effort within the OAuth working group is focused on > enhancing interoperability of OAuth deployments. While the core OAuth specification > truly is an important building block it relies on other specifications in order to > claim completeness. Luckily, these components already exist and have been deployed > on the Internet. Through the IETF standards process they will be improved in > quality and will undergo a rigorous review process. > > Goals and Milestones > > [Editor's Note: Here are the completed items.] > > Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item > Done Submit 'HTTP Authentication: MAC Authentication' as a working group item > Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard > Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard > > [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] > > May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard > May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard > May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard > May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC > Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard > > [Editor's Note: New work for the group] > > Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] > > Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC > > [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] > > Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-jones-simple-web-discovery] > > Mar. 2013 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token] > > Mar. 2013 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] > > Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Fri Apr 13 10:10:58 2012 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 7AADA21F863D for ; Fri, 13 Apr 2012 10:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.455 X-Spam-Level: X-Spam-Status: No, score=-5.455 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SC3rP43jIXSu for ; Fri, 13 Apr 2012 10:10:51 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF4021F8604 for ; Fri, 13 Apr 2012 10:10:51 -0700 (PDT) Received: from mail139-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Apr 2012 17:10:50 +0000 Received: from mail139-tx2 (localhost [127.0.0.1]) by mail139-tx2-R.bigfish.com (Postfix) with ESMTP id C14012001AD; Fri, 13 Apr 2012 17:10:50 +0000 (UTC) X-SpamScore: -43 X-BigFish: VS-43(z6caMzbb2dI9371I542M1432N98dK11fbI199bIzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail139-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail139-tx2 (localhost.localdomain [127.0.0.1]) by mail139-tx2 (MessageSwitch) id 1334337048117128_21915; Fri, 13 Apr 2012 17:10:48 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.237]) by mail139-tx2.bigfish.com (Postfix) with ESMTP id 0AEB64E009B; Fri, 13 Apr 2012 17:10:48 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Apr 2012 17:10:47 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0283.004; Fri, 13 Apr 2012 17:10:30 +0000 From: Mike Jones To: Justin Richer , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Updated Charter to the IESG (this weekend) Thread-Index: AQHNGJrBAuQglVZ/R0WeZTzlbF/CnpaY/QCAgAACPMA= Date: Fri, 13 Apr 2012 17:10:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> In-Reply-To: <4F885BF9.2080307@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Fri, 13 Apr 2012 17:10:59 -0000 Yes, there was an explicit decision in that regard. My sense was that the = WG did think they're important but they only wanted to take on a manageable= number of tasks at once. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ustin Richer Sent: Friday, April 13, 2012 10:02 AM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) Did the "Introspection Endpoint" or "Methods for connecting a PR to an AS" = get dropped? There seemed to be interest in the list in coming up with a ge= nerally applicable scheme, or set of schemes, to do this, and there are cer= tainly no shortage of starting points. Both AOL and Ping have their own tok= en introspection drafts that got put to the list, we've developed our own i= nternal approach here, UMA has an alternative approach, and OpenID Connect = has invented its own approach for ID Tokens. I just want to make sure that this was an explicit decision of it being out= of scope here and not an inadvertent omission. -- Justin On 04/12/2012 06:55 AM, Hannes Tschofenig wrote: > Hey guys > > based on the discussion before, during, and after the Paris IETF meeting = I am going to send the following updated charter / milestones to the IESG. > Please have a quick look (till the end of the week) to double-check the c= ontent (particularly the suggested milestone dates): > > ---------- > > > Web Authorization Protocol (oauth) > > Description of Working Group > > The Web Authorization (OAuth) protocol allows a user to grant a=20 > third-party Web site or application access to the user's protected=20 > resources, without necessarily revealing their long-term credentials,=20 > or even their identity. For example, a photo-sharing site that=20 > supports OAuth could allow its users to use a third-party printing Web=20 > site to print their private pictures, without allowing the printing=20 > site to gain full control of the user's account and without having the=20 > user sharing his or her photo-sharing sites' long-term credential with=20 > the printing site. > > The OAuth protocol suite encompasses > * a procedure for allowing a client to discover a resource server, > * a protocol for obtaining authorization tokens from an authorization=20 > server with the resource owner's consent, > * protocols for presenting these authorization tokens to protected=20 > resources for access to a resource, and > * consequently for sharing data in a security and privacy respective way. > > In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,=20 > was published as an informational document (RFC 5849). With the=20 > completion of OAuth 1.0 the working group started their work on OAuth=20 > 2.0 to incorporate implementation experience with version 1.0,=20 > additional use cases, and various other security, readability, and=20 > interoperability improvements. An extensive security analysis was=20 > conducted and the result is available as a stand-alone document=20 > offering guidance for audiences beyond the community of protocol implemen= ters. > > The working group also developed security schemes for presenting=20 > authorization tokens to access a protected resource. This led to the=20 > publication of the bearer token as well as the message authentication=20 > code (MAC) access authentication specification. > > OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH=20 > token with the SAML 2.0 bearer assertion profile. This offers=20 > interworking with existing identity management solutions, in particular S= AML based deployments. > > OAuth has enjoyed widespread adoption by the Internet application=20 > service provider community. To build on this success we aim for=20 > nothing more than to make OAuth the authorization framework of choice=20 > for any Internet protocol. Consequently, the ongoing standardization=20 > effort within the OAuth working group is focused on enhancing=20 > interoperability of OAuth deployments. While the core OAuth=20 > specification truly is an important building block it relies on other=20 > specifications in order to claim completeness. Luckily, these=20 > components already exist and have been deployed on the Internet. Through = the IETF standards process they will be improved in quality and will underg= o a rigorous review process. > > Goals and Milestones > > [Editor's Note: Here are the completed items.] > > Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a=20 > working group item Done Submit 'HTTP Authentication: MAC=20 > Authentication' as a working group item Done Submit 'The OAuth 2.0=20 > Protocol: Bearer Tokens' to the IESG for consideration as a Proposed=20 > Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the=20 > IESG for consideration as a Proposed Standard > > [Editor's Note: Finishing existing work. Double-check the proposed=20 > dates - are they realistic?] > > May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0'=20 > to the IESG for consideration as a Proposed Standard May 2012 Submit=20 > 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a=20 > Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace for=20 > OAuth' to the IESG for consideration as a Proposed Standard May 2012 =20 > Submit 'OAuth 2.0 Threat Model and Security Considerations' to the=20 > IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP=20 > Authentication: MAC Authentication' to the IESG for consideration as a=20 > Proposed Standard > > [Editor's Note: New work for the group] > > Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as=20 > a Proposed Standard > > [Starting point for the work will be=20 > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] > > Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as=20 > an Informational RFC > > [Starting point for the work will be=20 > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] > > Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration=20 > as a Proposed Standard > > [Starting point for the work will be=20 > http://tools.ietf.org/html/draft-jones-simple-web-discovery] > > Mar. 2013 Submit 'JSON Web Token (JWT)' to the IESG for consideration=20 > as a Proposed Standard > > [Starting point for the work will be=20 > http://tools.ietf.org/html/draft-jones-json-web-token] > > Mar. 2013 Submit 'JSON Web Token (JWT) Bearer Token Profiles for=20 > OAuth 2.0' to the IESG for consideration as a Proposed Standard > > [Starting point for the work will be=20 > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] > > Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the=20 > IESG for consideration as a Proposed Standard > > [Starting point for the work will be=20 > http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] > > > _______________________________________________ > 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 From wmills@yahoo-inc.com Fri Apr 13 10:15:47 2012 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 ADE0621F8797 for ; Fri, 13 Apr 2012 10:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.123 X-Spam-Level: X-Spam-Status: No, score=-17.123 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVVH2Ml-1kOO for ; Fri, 13 Apr 2012 10:15:46 -0700 (PDT) Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (nm12-vm0.bullet.mail.bf1.yahoo.com [98.139.213.140]) by ietfa.amsl.com (Postfix) with SMTP id 440FA21F877D for ; Fri, 13 Apr 2012 10:15:46 -0700 (PDT) Received: from [98.139.212.147] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2012 17:15:45 -0000 Received: from [98.139.212.193] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2012 17:15:45 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 13 Apr 2012 17:15:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 713520.94139.bm@omp1002.mail.bf1.yahoo.com Received: (qmail 63020 invoked by uid 60001); 13 Apr 2012 17:15:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334337345; bh=YwmNJjH0PwbzYPkAG5e/+78U5vZV30IJhg5Sf0IrXcU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eWlTG68GFj3WvjrUMkxYFWc56usl3avpHXjcctTMWLA8XoB9Sj+91FCblQJ6kpCwPuDzHBE4R8jMZJjKthVb1/PHaaoWNARVR4KCqfCMkb5STQKZoXrSepW6PSTPDF+nyxGgHWWqtVozbQUT3nZ/YG7e8gyOuyuUHa+EEy2xI+k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=q+E+m8gLGYec/EsixozGhzbPzWhTHlcPGBj031aUQ2lC6tWrYf9oyqUDmM58WZVUwLAOQMSczjtYo1Eidj43eHu2uik53C1kRa0cay/jIkp6seL+3zinzREHkzJfIx+ZQcza88/swR+nyTlBXK94VLsdI6uzsvMbgLKLZTuU5tM=; X-YMail-OSG: Xb5wVHIVM1mlmRLoFbOdzR1X2FTgwDpLKM6dju8MU1.FpPT 9o5TxAtmo_MbwIkY50bb37pCoQG8BEQr9c06Zhb6LNhFQ9u8yH4Yj4JtTZIi CSk3CXQLK1wQzFM0Gtg9L8tcZN_UCsEA53Byf_Me2GMkyVLInsVgEkTco_qn dxEg3QBoxUKZs1cSsk7IpoldqK5dPAn.mxy2J1K6CjyPVeaLt_E9M6S.YuYB C3t14p_cW_TV6tTOQQOdLgkSgXuFZaB6nOaws4KLNKbCk_TeQwuk0UGHlF7W RmRQ3fhwN1cqllGB_dkUmUpgZos_Y_hj4wunoAWUrR6zGGMh7RTV.ksaD9ZV oJ2t1qW8Pyi5arE.vqGzty.a1h9SlLPkfQPXWnp5EWkLBlsH9u_1VnVGD4IG OLVNuPJIXM2BuA1ziYhOXpkKztKSNWukCZDPmCIUD Received: from [99.31.212.42] by web31808.mail.mud.yahoo.com via HTTP; Fri, 13 Apr 2012 10:15:44 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F86C437.3000006@cs.tcd.ie> <4F871201.1000103@alcatel-lucent.com> <4F871EFB.6000807@alcatel-lucent.com> Message-ID: <1334337344.85710.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Fri, 13 Apr 2012 10:15:44 -0700 (PDT) From: William Mills To: "igor.faynberg@alcatel-lucent.com" , John Bradley In-Reply-To: <4F871EFB.6000807@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-1123531420-1334337344=:85710" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:15:47 -0000 --258328648-1123531420-1334337344=:85710 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Or perhaps update/extend the existing spec to do what is needed?=A0 Is ther= e anything that is fundamentally in conflict?=0A=0A-bill=0A=0A=0A=0A=0A>___= _____________________________=0A> From: Igor Faynberg =0A>To: John Bradley =0A>Cc: oauth@ietf.or= g =0A>Sent: Thursday, April 12, 2012 11:29 AM=0A>Subject: Re: [OAUTH-WG] We= b Finger vs. Simple Web Discovery (SWD)=0A> =0A>John,=0A>=0A>=A0 I agree wi= th you on everything you said about the differences.=A0 My =0A>question: Ar= e these not about API rather than the protocol?=0A>=0A>(I was just trying t= o see if I can find a common fixed point to start with.)=0A>=0A>Igor=0A>=0A= >On 4/12/2012 2:00 PM, John Bradley wrote:=0A>> There are important deploym= ent and privacy issues that caused openID Connect to use SWD.=0A>>=0A>> I w= as part of the OASIS XRI/XRD work that Web Finger has been based on.=0A>>= =0A>> The main differences are around allowing all of the users information= to be publicly discoverable, vs providing for access control.=0A>>=0A>> Th= ey are similar, but have real design differences.=0A>>=0A>> Web Finger with= out XML is not horrible by any means,=A0 but nether is SWD.=0A>>=0A>> SWD i= s more about users while host-meta is more about server resources.=0A>>=0A>= > John B.=0A>>=0A>>=0A>> On 2012-04-12, at 7:33 PM, Igor Faynberg wrote:=0A= >>=0A>>> To me this looks like more than the same problem being solved--it = appears to be the same protocol... I wonder if, the representation issues w= ere put aside (i.e., left to the API specification), the common part is wha= t can be adopted.=0A>>>=0A>>> Igor=0A>>>=0A>>> On 4/12/2012 8:01 AM, Stephe= n Farrell wrote:=0A>>>>=0A>>>> On 04/12/2012 12:00 PM, Hannes Tschofenig wr= ote:=0A>>>>> Hi all,=0A>>>>>=0A>>>>> those who had attended the last IETF m= eeting may have noticed the ongoing activity in the 'Applications Area Work= ing Group' regarding Web Finger.=0A>>>>> We had our discussion regarding Si= mple Web Discovery (SWD) as part of the re-chartering process.=0A>>>>>=0A>>= >>> Here are the two specifications:=0A>>>>> http://tools.ietf.org/html/dra= ft-jones-appsawg-webfinger-03=0A>>>>> http://tools.ietf.org/html/draft-jone= s-simple-web-discovery-02=0A>>>>>=0A>>>>> Now, the questions that seems to = be hanging around are=0A>>>>>=0A>>>>>=A0 =A0 1) Aren't these two mechanisms= solving pretty much the same problem?=0A>>>>>=A0 =A0 2) Do we need to have= two standards for the same functionality?=0A>>>>>=A0 =A0 3) Do you guys ha= ve a position or comments regarding either one of them?=0A>>>>>=0A>>>>> Cia= o=0A>>>>> Hannes=0A>>>>>=0A>>>>> PS: Please also let me know if your view i= s: "I don't really know what all this is about and the documents actually d= on't provide enough requirements to make a reasonable judgement about the s= olution space."=0A>>>>>=0A>>>> So just as a data-point. We (the IETF, but i= ncluding=0A>>>> me personally;-) mucked up badly on this some years=0A>>>> = ago in the PKI space - we standardised both CMP (rfc=0A>>>> 2510) and CMC (= rfc 2797) as two ways to do the same=0A>>>> thing, after a protracted battl= e between factions=0A>>>> supporting one or the other. We even made sure th= ey=0A>>>> had as much common syntax as possible. (CRMF, rfc=0A>>>> 2511)=0A= >>>>=0A>>>> Result: neither fully adopted, lots of people still=0A>>>> do p= roprietary stuff, neither can be killed off=0A>>>> (despite attempts), both= need to be maintained (CMP=0A>>>> is now RFC 4210, CMC, 5272, CRMF, 4211),= and IMO=0A>>>> partly as a result of us screwing up for what seemed=0A>>>>= like good reasons at the time, PKI administration=0A>>>> stuff has never g= otten beyond horrible-to-do.=0A>>>>=0A>>>> All-in-all, a really bad outcome= which is still=0A>>>> a PITA a dozen years later.=0A>>>>=0A>>>> As OAuth A= D I will need *serious* convincing that=0A>>>> there is a need to provide t= wo ways to do the same=0A>>>> thing. I doubt it'll be possible to convince = me,=0A>>>> in fact, so if you wanna try, you'll need to start=0A>>>> by say= ing that they are not in fact two ways to do=0A>>>> the same thing:-)=0A>>>= >=0A>>>> S.=0A>>>>=0A>>>> PS: This discussion needs to also involve the App= s=0A>>>> area, so I've cc'd that list.=0A>>>>=0A>>>>>=0A>>>>>=0A>>>>> _____= __________________________________________=0A>>>>> OAuth mailing list=0A>>>= >> OAuth@ietf.org=0A>>>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>>= >>=0A>>>> _______________________________________________=0A>>>> OAuth mail= ing list=0A>>>> OAuth@ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo= /oauth=0A>>> _______________________________________________=0A>>> OAuth ma= iling list=0A>>> OAuth@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo= /oauth=0A>_______________________________________________=0A>OAuth mailing = list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>= =0A>=0A> --258328648-1123531420-1334337344=:85710 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Or perhaps update/extend the existing spec to do what is needed?  Is= there anything that is fundamentally in conflict?

-bill

From: Igor Faynberg <igor.faynberg@alcatel-= lucent.com>
To: Joh= n Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org
Sent: Thursday, April 12, 2012 11:29 AM
Subject: Re: [OAUTH-WG] Web Finger vs. S= imple Web Discovery (SWD)

=0AJohn,

  I a= gree with you on everything you said about the differences.  My
qu= estion: Are these not about API rather than the protocol?

(I was jus= t trying to see if I can find a common fixed point to start with.)

I= gor

On 4/12/2012 2:00 PM, John Bradley wrote:
> There are impo= rtant deployment and privacy issues that caused openID Connect to use SWD.<= br>>
> I was part of the OASIS XRI/XRD work that Web Finger has be= en based on.
>
> The main differences are around allowing all o= f the users information to be publicly discoverable, vs providing for acces= s control.
>
> They are similar, but have real design differenc= es.
>
> Web Finger without XML is not horrible by any means,&nb= sp; but nether is SWD.
>
> SWD is more about users while host-m= eta is more about server resources.
>
> John B.
>
>=
> On 2012-04-12, at 7:33 PM, Igor Faynberg wrote:
>
>> To me this looks like more than the sa= me problem being solved--it appears to be the same protocol... I wonder if,= the representation issues were put aside (i.e., left to the API specificat= ion), the common part is what can be adopted.
>>
>> Igor<= br>>>
>> On 4/12/2012 8:01 AM, Stephen Farrell wrote:
>= ;>>
>>> On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:<= br>>>>> Hi all,
>>>>
>>>> those w= ho had attended the last IETF meeting may have noticed the ongoing activity= in the 'Applications Area Working Group' regarding Web Finger.
>>= >> We had our discussion regarding Simple Web Discovery (SWD) as part= of the re-chartering process.
>>>>
>>>> Here= are the two specifications:
>>>> http://tools.ietf.org/html= /draft-jones-appsawg-webfinger-03
>>>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02
>>= >>
>>>> Now, the questions that seems to be hanging ar= ound are
>>>>
>>>>    1) Aren't the= se two mechanisms solving pretty much the same problem?
>>>>=     2) Do we need to have two standards for the same functionalit= y?
>>>>    3) Do you guys have a position or comme= nts regarding either one of them?
>>>>
>>>> C= iao
>>>> Hannes
>>>>
>>>> PS: = Please also let me know if your view is: "I don't really know what all this= is about and the documents actually don't provide enough requirements to m= ake a reasonable judgement about the solution space."
>>>>>>> So just as a data-point. We (the IETF, but including
>= >> me personally;-) mucked up badly on this some years
>>> ago in the PKI space - we standardised both CMP (rfc=
>>> 2510) and CMC (rfc 2797) as two ways to do the same
>= ;>> thing, after a protracted battle between factions
>>>= supporting one or the other. We even made sure they
>>> had as= much common syntax as possible. (CRMF, rfc
>>> 2511)
>&g= t;>
>>> Result: neither fully adopted, lots of people still<= br>>>> do proprietary stuff, neither can be killed off
>>= > (despite attempts), both need to be maintained (CMP
>>> is= now RFC 4210, CMC, 5272, CRMF, 4211), and IMO
>>> partly as a = result of us screwing up for what seemed
>>> like good reasons = at the time, PKI administration
>>> stuff has never gotten beyo= nd horrible-to-do.
>>>
>>> All-in-all, a really bad= outcome which is still
>>> a PITA a dozen years later.
>>>
>>> As OAuth AD I will need *serious* c= onvincing that
>>> there is a need to provide two ways to do th= e same
>>> thing. I doubt it'll be possible to convince me,
= >>> in fact, so if you wanna try, you'll need to start
>>= > by saying that they are not in fact two ways to do
>>> the= same thing:-)
>>>
>>> S.
>>>
>&g= t;> PS: This discussion needs to also involve the Apps
>>> a= rea, so I've cc'd that list.
>>>
>>>>
>>= ;>>
>>>> _____________________________________________= __
>>>> OAuth mailing list
>>>> OAuth@ietf.org>>>> https://www.ietf.org/mailman/listinfo/oauth
>&= gt;>>
>>> _______________________________________________=
>>> OAuth mailing list
>>> OAuth@ietf.org
>>= > https://www.ietf.org/mailman/listinfo/oauth
>> ___________= ____________________________________
>> OAuth mailing list
>= > OA= uth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth=
_______________________________________________
OAuth mailing listOAuth= @ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
--258328648-1123531420-1334337344=:85710-- From cmortimore@salesforce.com Fri Apr 13 10:20:16 2012 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 C2C7D21F87A5 for ; Fri, 13 Apr 2012 10:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywhtWuUTLjD9 for ; Fri, 13 Apr 2012 10:20:14 -0700 (PDT) Received: from exprod8og116.obsmtp.com (exprod8og116.obsmtp.com [64.18.3.32]) by ietfa.amsl.com (Postfix) with SMTP id 04CCA21F87A2 for ; Fri, 13 Apr 2012 10:20:13 -0700 (PDT) Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob116.postini.com ([64.18.7.12]) with SMTP ID DSNKT4hgTQf7M8bGvYN9PF9T9xaZpcRWiBLd@postini.com; Fri, 13 Apr 2012 10:20:14 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.57]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Fri, 13 Apr 2012 10:20:13 -0700 From: Chuck Mortimore To: "Zeltsan, Zachary (Zachary)" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "oauth@ietf.org" Date: Fri, 13 Apr 2012 10:20:10 -0700 Thread-Topic: [OAUTH-WG] WGLC on Assertion Drafts Thread-Index: Ac0TOvMdI0KJHLgrSYOXF98LEO+MPAALZYCwAYxJK94= Message-ID: In-Reply-To: <5710F82C0E73B04FA559560098BF95B1250DE5716F@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBADAE5A2A162cmortimoresalesforcecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] WGLC on Assertion Drafts 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: Fri, 13 Apr 2012 17:20:17 -0000 --_000_CBADAE5A2A162cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zachary - sorry about the delay in responding. Perhaps the language is a bit confusing - let me explain the intent and see= if it makes sense and if you have a recommendation on how it could be made= clearer. All this is really saying is that the Authorization server must validate th= e signature to make sure the Issuer is who they say they are. The authori= zation server would use the Issuer as it's mechanism for looking up either = the shared secret for an HS256 or the public key for RS256. It then check= s the signature, and proves to itself that the generator of the assertion h= ad possession of the expected keying material and identified itself as the = issuer. Feedback welcome -cmort On 4/5/12 1:33 PM, "Zeltsan, Zachary (Zachary)" wrote: Hello, The draft http://tools.ietf.org/html/draft-ietf-oauth-assertions-01, sectio= n 6.1 has the following requirement: The Authorization Server MUST validate the assertion in order to establish a mapping between the Issuer and the secret used to generat= e the assertion. I thought that checking a signature is a part of the assertion validation, = which cannot be done without knowing the mapping between the issuer and the= secret used to generate the assertion. It appears that the quoted text requires validation of the assertion prior = to checking the signature. What am I missing? Zachary From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= schofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, April 05, 2012 10:47 AM To: oauth@ietf.org Subject: [OAUTH-WG] WGLC on Assertion Drafts Hi all, this is a Last Call for comments on these three documents: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10 http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02 Please have your comments in no later than April 23rd. Do remember to send a note in if you have read the document and have no oth= er comments other than "it's ready to go" - we need those as much as we nee= d "I found a problem". Thanks! Hannes & Derek --_000_CBADAE5A2A162cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] WGLC on Assertion Drafts Hi Zachary R= 11; sorry about the delay in responding.

Perhaps the language is a bit confusing – let me explain the intent a= nd see if it makes sense and if you have a recommendation on how it could b= e made clearer.

All this is really saying is that the Authorization server must validate th= e signature to make sure the Issuer is who they say they are.   T= he authorization server would use the Issuer as it’s mechanism for lo= oking up either the shared secret for an HS256 or the public key for RS256.=   It then checks the signature, and proves to itself that the ge= nerator of the assertion had possession of the expected keying material and= identified itself as the issuer.

Feedback welcome

-cmort

On 4/5/12 1:33 PM, "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com>= ; wrote:

Hello,
 
The draft http://tools.ietf.org/html/draft= -ietf-oauth-assertions-01, section 6.1 has the following requirement:
The Authorization Server MUST validate the assertion in order to
      establish a mapping between the Issuer = and the secret used to generate the assertion.
 
I thought that checking a signature is a part of the assertion validation, = which cannot be done without knowing the mapping between the issuer and the= secret used to generate the assertion.
It appears that the quoted text requires validation of the assertion prior = to checking the signature.
What am I missing?
 
Zachary
 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of <= /B>Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, April 05, 2012 10:47 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] WGLC on Assertion Drafts
H= i all,
<= BR> this is a Last Call for comments on t= hese three documents:

http://tools.ietf.org/html/draft-ietf-oa= uth-saml2-bearer-10

http://tools.ietf.org/html/draft-ietf-oaut= h-assertions-01

http://tools.ietf.org/html/draft-ietf-oaut= h-urn-sub-ns-02

Please have your comments in no later= than April 23rd.

Do remember to send a note in if you = have read the document and have no other comments other than "it’= ;s ready to go" - we need those as much as we need "I found a pro= blem".

Thanks!

Hannes & Derek

--_000_CBADAE5A2A162cmortimoresalesforcecom_-- From zachary.zeltsan@alcatel-lucent.com Fri Apr 13 10:39:00 2012 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 12CD211E80A4 for ; Fri, 13 Apr 2012 10:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NO0CgvAJJML for ; Fri, 13 Apr 2012 10:38:59 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 788C611E8086 for ; Fri, 13 Apr 2012 10:38:59 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q3DHcw43027438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Apr 2012 12:38:58 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3DHcwcB030264 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 13 Apr 2012 12:38:58 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 13 Apr 2012 12:38:58 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'oauth@ietf.org'" Date: Fri, 13 Apr 2012 12:38:55 -0500 Thread-Topic: New Version Notification for draft-zeltsan-oauth-use-cases-03.txt Thread-Index: Ac0Zm4LKfhMT9lXlRqKE1ptOvs5ddwAAA9KQ Message-ID: <5710F82C0E73B04FA559560098BF95B1250E8BAD25@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [OAUTH-WG] FW: New Version Notification for draft-zeltsan-oauth-use-cases-03.txt 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: Fri, 13 Apr 2012 17:39:00 -0000 Rm9sbG93aW5nLXVwIG9uIHRoZSBPQVVUSCBXRyByZS1jaGFydGVyaW5nIGRpc2N1c3Npb24gSSBo YXZlIHN1Ym1pdHRlZCBhbiB1cGRhdGVkIGRyYWZ0IG9uIHRoZSBPQXV0aCB1c2UgY2FzZXMuDQpD b21wYXJlZCB0byB0aGUgcHJldmlvdXMgdmVyc2lvbiB0aGVyZSBhcmUgb25seSBtaW5vciBjaGFu Z2VzIGluIHRoZSBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uIHNlY3Rpb25zLg0KDQpBbGwgY29t bWVudHMgYXJlIHdlbGNvbWVkLg0KDQpaYWNoYXJ5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBBcHJpbCAxMywgMjAxMiAxOjMzIFBNDQpUbzog WmVsdHNhbiwgWmFjaGFyeSAoWmFjaGFyeSkNCkNjOiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDsg Z2ZmbGV0Y2hAYW9sLmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC16ZWx0c2FuLW9hdXRoLXVzZS1jYXNlcy0wMy50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LXplbHRzYW4tb2F1dGgtdXNlLWNhc2VzLTAzLnR4dCBoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IFphY2hhcnkgWmVsdHNhbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtemVsdHNhbi1vYXV0aC11c2UtY2FzZXMN ClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIE9BdXRoIFVzZSBDYXNlcw0KQ3JlYXRpb24gZGF0ZToJ IDIwMTItMDQtMTMNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBh Z2VzOiAyMw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgbGlzdHMgdGhlIE9BdXRoIHVz ZSBjYXNlcy4gIFRoZSBwcm92aWRlZCBsaXN0IGlzIGJhc2VkDQogICBvbiB0aGUgSW50ZXJuZXQt RHJhZnRzIG9mIHRoZSBPQVVUSCB3b3JraW5nIGdyb3VwIGFuZCBkaXNjdXNzaW9ucyBvbg0KICAg dGhlIGdyb3VwJiMzOTtzIG1haWxpbmcgbGlzdC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From msk@cloudmark.com Fri Apr 13 10:45:59 2012 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 EB24D21F87A0 for ; Fri, 13 Apr 2012 10:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO9y2KlbCk9G for ; Fri, 13 Apr 2012 10:45:59 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 64C5821F8787 for ; Fri, 13 Apr 2012 10:45:59 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id xVlZ1i0010as01C01VlZGx; Fri, 13 Apr 2012 10:45:36 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=H85ZMpki c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=Vhm4rtfK4QIA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=EGYWwU0pP8kselV1ijEA:9 a=TMeAxP0eBW1KDgzFfd8A:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 10:45:33 -0700 From: "Murray S. Kucherawy" To: Stephen Farrell , "oauth@ietf.org WG" Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNGZGq3EJC/uqAeEiJeS7yiAAyipaZBtVQ Date: Fri, 13 Apr 2012 17:45:32 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> In-Reply-To: <4F8852D0.4020404@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334339136; bh=ZXjRX4lUDWq1QkHwOSk5FhP00wMJVfUHqavDsz4qz6Y=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=F3IkKM5QNg6j0mOnlTm8CvSKqOfwj2t63xHjZrsl1bSCvZj1Da/kdVPk7iv15kUcB hd2xmks0kOBAcFDg+aLtdD+RLHEnc9tLA2/ATdCJOpQefaZgA2X045zk4yj8W8MLg8 Ecc+VyaTOxNRGxZJ7WyjtepCvr6u9MOKaBgpxXnc= Cc: Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 13 Apr 2012 17:46:00 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Stephen Farrell > Sent: Friday, April 13, 2012 9:23 AM > To: oauth@ietf.org WG > Cc: Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discover= y (SWD) >=20 > So Hannes and Derek and I have been discussing this with the Apps ADs > and Apps-area WG chairs. I've also read the docs now, and after all > that we've decided that this topic (what to do with swd and webfinger) > is best handled in the apps area and not in the oauth WG. >=20 > The logic for that is that 1) the two proposals are doing the same > thing and we don't want two different standards for that, b) this is > not an oauth-specific thing nor is it a general security thing, and c) > there is clearly already interest in the topic in the apps area so its > reasonable for the oauth wg to use that when its ready. >=20 > The appsawg chairs and apps ADs are ok with the work being done there. >=20 > So:- >=20 > - I've asked the oauth chairs to take doing work on swd > out of the proposed new charter > - It may be that you want to add something saying that > oauth will use the results of work in the applications > area on a web discovery protocol as a basis for doing > the dynamic client registration work here > - Discussion of webfinger and swd should move over to > the apps-discuss list > - Note: this is not picking one or the other approach, > the plan is that the apps area will do any selection > needed and figure out the best starting point for a > standards-track RFC on web discovery and we'll use their > fine work for doing more with oauth. Thank you Stephen, I think. :-) So the discussion on apps-discuss now should be focused on which of the two= should be the basis for forward progress. I've placed both documents in "= Call for Adoption" state in the datatracker for appsawg. Let the games begin. -MSK From jricher@mitre.org Fri Apr 13 11:33:02 2012 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 8A72121F8528 for ; Fri, 13 Apr 2012 11:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JRylUKlnTFq for ; Fri, 13 Apr 2012 11:33:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7F94921F84C9 for ; Fri, 13 Apr 2012 11:33:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0772521B16A2; Fri, 13 Apr 2012 14:33:01 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E12CA21B00F9; Fri, 13 Apr 2012 14:33:00 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 13 Apr 2012 14:33:00 -0400 Message-ID: <4F88713C.6070309@mitre.org> Date: Fri, 13 Apr 2012 14:32:28 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Mike Jones References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Fri, 13 Apr 2012 18:33:02 -0000 OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? -- Justin On 04/13/2012 01:10 PM, Mike Jones wrote: > Yes, there was an explicit decision in that regard. My sense was that the WG did think they're important but they only wanted to take on a manageable number of tasks at once. > > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer > Sent: Friday, April 13, 2012 10:02 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) > > Did the "Introspection Endpoint" or "Methods for connecting a PR to an AS" get dropped? There seemed to be interest in the list in coming up with a generally applicable scheme, or set of schemes, to do this, and there are certainly no shortage of starting points. Both AOL and Ping have their own token introspection drafts that got put to the list, we've developed our own internal approach here, UMA has an alternative approach, and OpenID Connect has invented its own approach for ID Tokens. > > I just want to make sure that this was an explicit decision of it being out of scope here and not an inadvertent omission. > > -- Justin > > On 04/12/2012 06:55 AM, Hannes Tschofenig wrote: >> Hey guys >> >> based on the discussion before, during, and after the Paris IETF meeting I am going to send the following updated charter / milestones to the IESG. >> Please have a quick look (till the end of the week) to double-check the content (particularly the suggested milestone dates): >> >> ---------- >> >> >> Web Authorization Protocol (oauth) >> >> Description of Working Group >> >> The Web Authorization (OAuth) protocol allows a user to grant a >> third-party Web site or application access to the user's protected >> resources, without necessarily revealing their long-term credentials, >> or even their identity. For example, a photo-sharing site that >> supports OAuth could allow its users to use a third-party printing Web >> site to print their private pictures, without allowing the printing >> site to gain full control of the user's account and without having the >> user sharing his or her photo-sharing sites' long-term credential with >> the printing site. >> >> The OAuth protocol suite encompasses >> * a procedure for allowing a client to discover a resource server, >> * a protocol for obtaining authorization tokens from an authorization >> server with the resource owner's consent, >> * protocols for presenting these authorization tokens to protected >> resources for access to a resource, and >> * consequently for sharing data in a security and privacy respective way. >> >> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, >> was published as an informational document (RFC 5849). With the >> completion of OAuth 1.0 the working group started their work on OAuth >> 2.0 to incorporate implementation experience with version 1.0, >> additional use cases, and various other security, readability, and >> interoperability improvements. An extensive security analysis was >> conducted and the result is available as a stand-alone document >> offering guidance for audiences beyond the community of protocol implementers. >> >> The working group also developed security schemes for presenting >> authorization tokens to access a protected resource. This led to the >> publication of the bearer token as well as the message authentication >> code (MAC) access authentication specification. >> >> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH >> token with the SAML 2.0 bearer assertion profile. This offers >> interworking with existing identity management solutions, in particular SAML based deployments. >> >> OAuth has enjoyed widespread adoption by the Internet application >> service provider community. To build on this success we aim for >> nothing more than to make OAuth the authorization framework of choice >> for any Internet protocol. Consequently, the ongoing standardization >> effort within the OAuth working group is focused on enhancing >> interoperability of OAuth deployments. While the core OAuth >> specification truly is an important building block it relies on other >> specifications in order to claim completeness. Luckily, these >> components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. >> >> Goals and Milestones >> >> [Editor's Note: Here are the completed items.] >> >> Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a >> working group item Done Submit 'HTTP Authentication: MAC >> Authentication' as a working group item Done Submit 'The OAuth 2.0 >> Protocol: Bearer Tokens' to the IESG for consideration as a Proposed >> Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the >> IESG for consideration as a Proposed Standard >> >> [Editor's Note: Finishing existing work. Double-check the proposed >> dates - are they realistic?] >> >> May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' >> to the IESG for consideration as a Proposed Standard May 2012 Submit >> 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a >> Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace for >> OAuth' to the IESG for consideration as a Proposed Standard May 2012 >> Submit 'OAuth 2.0 Threat Model and Security Considerations' to the >> IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP >> Authentication: MAC Authentication' to the IESG for consideration as a >> Proposed Standard >> >> [Editor's Note: New work for the group] >> >> Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as >> a Proposed Standard >> >> [Starting point for the work will be >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] >> >> Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as >> an Informational RFC >> >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] >> >> Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration >> as a Proposed Standard >> >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-jones-simple-web-discovery] >> >> Mar. 2013 Submit 'JSON Web Token (JWT)' to the IESG for consideration >> as a Proposed Standard >> >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-jones-json-web-token] >> >> Mar. 2013 Submit 'JSON Web Token (JWT) Bearer Token Profiles for >> OAuth 2.0' to the IESG for consideration as a Proposed Standard >> >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] >> >> Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the >> IESG for consideration as a Proposed Standard >> >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] >> >> >> _______________________________________________ >> 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 > > From zachary.zeltsan@alcatel-lucent.com Fri Apr 13 11:55:27 2012 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 47AA521F8564 for ; Fri, 13 Apr 2012 11:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w27cVr3S8JAv for ; Fri, 13 Apr 2012 11:55:25 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 218AC21F8557 for ; Fri, 13 Apr 2012 11:55:25 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q3DItLwj004605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Apr 2012 13:55:22 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3DItLMR031696 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Apr 2012 13:55:21 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 13 Apr 2012 13:55:21 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Chuck Mortimore'" , "'Tschofenig, Hannes (NSN - FI/Espoo)'" , "'oauth@ietf.org'" Date: Fri, 13 Apr 2012 13:55:18 -0500 Thread-Topic: [OAUTH-WG] WGLC on Assertion Drafts Thread-Index: Ac0TOvMdI0KJHLgrSYOXF98LEO+MPAALZYCwAYxJK94AA0dS0A== Message-ID: <5710F82C0E73B04FA559560098BF95B1250E8BAD72@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B1250DE5716F@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B1250E8BAD72USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [OAUTH-WG] WGLC on Assertion Drafts 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: Fri, 13 Apr 2012 18:55:27 -0000 --_000_5710F82C0E73B04FA559560098BF95B1250E8BAD72USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chuck, The intent is clear. Perhaps the following change would clarify the text: Old: The Authorization Server MUST validate the assertion in order to estab= lish a mapping between the Issuer and the secret used to generate the asser= tion. New: The Authorization Server MUST validate the assertion's signature in or= der to verify the Issuer of the assertion. Zachary From: Chuck Mortimore [mailto:cmortimore@salesforce.com] Sent: Friday, April 13, 2012 1:20 PM To: Zeltsan, Zachary (Zachary); Tschofenig, Hannes (NSN - FI/Espoo); oauth@= ietf.org Subject: Re: [OAUTH-WG] WGLC on Assertion Drafts Hi Zachary - sorry about the delay in responding. Perhaps the language is a bit confusing - let me explain the intent and see= if it makes sense and if you have a recommendation on how it could be made= clearer. All this is really saying is that the Authorization server must validate th= e signature to make sure the Issuer is who they say they are. The authori= zation server would use the Issuer as it's mechanism for looking up either = the shared secret for an HS256 or the public key for RS256. It then check= s the signature, and proves to itself that the generator of the assertion h= ad possession of the expected keying material and identified itself as the = issuer. Feedback welcome -cmort On 4/5/12 1:33 PM, "Zeltsan, Zachary (Zachary)" wrote: Hello, The draft http://tools.ietf.org/html/draft-ietf-oauth-assertions-01, sectio= n 6.1 has the following requirement: The Authorization Server MUST validate the assertion in order to establish a mapping between the Issuer and the secret used to generat= e the assertion. I thought that checking a signature is a part of the assertion validation, = which cannot be done without knowing the mapping between the issuer and the= secret used to generate the assertion. It appears that the quoted text requires validation of the assertion prior = to checking the signature. What am I missing? Zachary From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= schofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, April 05, 2012 10:47 AM To: oauth@ietf.org Subject: [OAUTH-WG] WGLC on Assertion Drafts Hi all, this is a Last Call for comments on these three documents: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10 http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02 Please have your comments in no later than April 23rd. Do remember to send a note in if you have read the document and have no oth= er comments other than "it's ready to go" - we need those as much as we nee= d "I found a problem". Thanks! Hannes & Derek --_000_5710F82C0E73B04FA559560098BF95B1250E8BAD72USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] WGLC on Assertion Draf= ts

Chuc= k,

 <= /span>

The intent is clear. Perhaps the= following change would clarify the text:

New: The Authorization Se= rver MUST validate the assertion’s signature in order to verify = the Issuer of the assertion.

 = ;

Zachary

 

 

From: Chuck Mortimore [mailto:cmortimore@salesforce.com]
= Sent: Friday, April 13, 2012 1:20 PM
To: Zeltsan, Zachary (Za= chary); Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] WGLC on Assertion Drafts

 

Hi Zachary – sorry about the delay in responding.
<= br>Perhaps the language is a bit confusing – let me explain the inten= t and see if it makes sense and if you have a recommendation on how it coul= d be made clearer.

All this is really saying is that the Authorizati= on server must validate the signature to make sure the Issuer is who they s= ay they are.   The authorization server would use the Issuer as i= t’s mechanism for looking up either the shared secret for an HS256 or= the public key for RS256.   It then checks the signature, and pr= oves to itself that the generator of the assertion had possession of the ex= pected keying material and identified itself as the issuer.

Feedback= welcome

-cmort

On 4/5/12 1:33 PM, "Zeltsan, Zachary (Z= achary)" <zachary.ze= ltsan@alcatel-lucent.com> wrote:

Hello,
 
The draft http://tools.ietf.org/html/draft-i= etf-oauth-assertions-01, section 6.1 has the following requirement:
=
The Authorization Server MUST validate the assertion in order to
&n= bsp;     establish a mapping between the Issuer an= d the secret used to generate the assertion.
 
I thought that ch= ecking a signature is a part of the assertion validation, which cannot be d= one without knowing the mapping between the issuer and the secret used to g= enerate the assertion.
It appears that the quoted text requires validati= on of the assertion prior to checking the signature.
What am I missing?<= br> 
Zachary
 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Tschofenig, = Hannes (NSN - FI/Espoo)
Sent: Thursday, April 05, 2012 10:47 AMTo: oauth@ietf.org
Subject: [OAUTH-WG] WGLC on Assertion Drafts

Hi all,

this is a Last Call for comments on these th= ree documents:

http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10
http://tools.ietf.or= g/html/draft-ietf-oauth-assertions-01

http://tools.ietf.org/html/draft-ietf-oauth-ur= n-sub-ns-02

Please have your comments in no later than April 23rd.

Do remember to send = a note in if you have read the document and have no other comments other th= an "it’s ready to go" - we need those as much as we need &q= uot;I found a problem".

Thanks!

Hannes & Derek

<= /html>= --_000_5710F82C0E73B04FA559560098BF95B1250E8BAD72USNAVSXCHMBSA_-- From Adam.Lewis@motorolasolutions.com Fri Apr 13 12:13:34 2012 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 CF71821F8779 for ; Fri, 13 Apr 2012 12:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7MBLdA5X4ml for ; Fri, 13 Apr 2012 12:13:33 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7FA21F877B for ; Fri, 13 Apr 2012 12:13:32 -0700 (PDT) Received: from mail72-am1-R.bigfish.com (10.3.201.238) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Apr 2012 19:13:31 +0000 Received: from mail72-am1 (localhost [127.0.0.1]) by mail72-am1-R.bigfish.com (Postfix) with ESMTP id F1C14A0522 for ; Fri, 13 Apr 2012 19:13:31 +0000 (UTC) X-SpamScore: 0 X-BigFish: VPS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h683h839hd25h) X-Forefront-Antispam-Report: CIP:129.188.136.17; KIP:(null); UIP:(null); IPV:NLI; H:il06msg01.mot-solutions.com; RD:none; EFVD:NLI Received-SPF: pass (mail72-am1: domain of motorolasolutions.com designates 129.188.136.17 as permitted sender) client-ip=129.188.136.17; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg01.mot-solutions.com ; olutions.com ; Received: from mail72-am1 (localhost.localdomain [127.0.0.1]) by mail72-am1 (MessageSwitch) id 1334344409326498_12041; Fri, 13 Apr 2012 19:13:29 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.252]) by mail72-am1.bigfish.com (Postfix) with ESMTP id 4396140069 for ; Fri, 13 Apr 2012 19:13:29 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Apr 2012 19:13:27 +0000 Received: from il06msg01.mot-solutions.com (il06vts02.mot.com [129.188.137.142]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3DJtpeB029933 for ; Fri, 13 Apr 2012 14:55:51 -0500 (CDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3DJtoeP029921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Apr 2012 14:55:51 -0500 (CDT) Received: from mail137-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Apr 2012 19:13:24 +0000 Received: from mail137-va3 (localhost [127.0.0.1]) by mail137-va3-R.bigfish.com (Postfix) with ESMTP id CB320120126 for ; Fri, 13 Apr 2012 19:13:24 +0000 (UTC) Received: from mail137-va3 (localhost.localdomain [127.0.0.1]) by mail137-va3 (MessageSwitch) id 133434440372408_14993; Fri, 13 Apr 2012 19:13:23 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.241]) by mail137-va3.bigfish.com (Postfix) with ESMTP id 07B5A60155; Fri, 13 Apr 2012 19:13:23 +0000 (UTC) Received: from BL2PRD0410HT003.namprd04.prod.outlook.com (157.56.240.85) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Apr 2012 19:13:19 +0000 Received: from BL2PRD0410MB363.namprd04.prod.outlook.com ([169.254.3.6]) by BL2PRD0410HT003.namprd04.prod.outlook.com ([10.255.99.38]) with mapi id 14.16.0143.004; Fri, 13 Apr 2012 19:13:18 +0000 From: Lewis Adam-CAL022 To: Justin Richer Thread-Topic: [OAUTH-WG] Using OAuth to get a JWT/SAML token Thread-Index: AQHNGZQHGnbSav9o6k2Y2ikZeKN005aZHXKw Date: Fri, 13 Apr 2012 19:13:18 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A90741A7@BL2PRD0410MB363.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A906E74E@CH1PRD0410MB369.namprd04.prod.outlook.com> <4F885680.5090801@mitre.org> In-Reply-To: <4F885680.5090801@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.152.46] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A90741A7BL2PRD0410MB363na_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0410HT003.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False;00160000;True;; X-OrganizationHeadersPreserved: BL2PRD0410HT003.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MITRE.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Fri, 13 Apr 2012 19:13:35 -0000 --_000_59E470B10C4630419ED717AC79FCF9A90741A7BL2PRD0410MB363na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Justin ... In your application, to start things off, you fire off a web browser to the= authorization server's authorization endpoint. The user logs in to the aut= horization server through the web browser, approves this copy of your app, = and gets redirected to "myapp://oauthcallback?code=3Dbasdf132". Your app gr= abs the "myapp://" url and plucks the authorization code off the end of it.= Your app then takes that code and sends it in the background to the token = endpoint to exchange for a token. this is the part I'm missing. I understand how to get the authorizat= ion code to the client ... I think what you're saying is that when the cli= ent present the access code to the token endpoint, that the token endpoint = can return either a SAML or JWT token? Is the token endpoint typically par= t of the Authorization Server? Is the type of token returned (SAML/JWT/etc= ) depending on the implementation and what is supported by different vendor= s and open source, or is this required by the standard? OAuth 2.0 doesn't = really say a whole lot about the actual access token. Is this all consider= ed out of band from OAuth and a matter of implementation? Btw ... I curren= tly have two OAuth implementations running in the lab ... an evaluation cop= y of PingFederate and an open source stack (OpenAM). --_000_59E470B10C4630419ED717AC79FCF9A90741A7BL2PRD0410MB363na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Justin … <= /o:p>

 =

In your application, to start things off, you fire o= ff a web browser to the authorization server's authorization endpoint. The = user logs in to the authorization server through the web browser, approves = this copy of your app, and gets redirected to "myapp://oauthcallback?code=3Dbasdf132". Your app grabs the &= quot;myapp://" url and plucks the authorization code off the end of it= . Your app then takes that code and sends it in the background to the token= endpoint to exchange for a token.

&n= bsp;

<acl> this is the part I’m missing.  I= understand how to get the authorization code to the client …  I= think what you’re saying is that when the client present the access code to the token endpoint, that the token endpoint can return either a SA= ML or JWT token?  Is the token endpoint typically part of the Authoriz= ation Server?  Is the type of token returned (SAML/JWT/etc) depending = on the implementation and what is supported by different vendors and open source, or is this required by the standard?=   OAuth 2.0 doesn’t really say a whole lot about the actual acce= ss token.  Is this all considered out of band from OAuth and a matter = of implementation?  Btw … I currently have two OAuth implementations running in the lab … an evaluation copy of PingFeder= ate and an open source stack (OpenAM). </acl>

 

--_000_59E470B10C4630419ED717AC79FCF9A90741A7BL2PRD0410MB363na_-- From ve7jtb@ve7jtb.com Fri Apr 13 12:56:03 2012 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 A903F11E80F1 for ; Fri, 13 Apr 2012 12:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+sFd10zCazC for ; Fri, 13 Apr 2012 12:56:03 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4C6B11E80EF for ; Fri, 13 Apr 2012 12:56:01 -0700 (PDT) Received: by werb10 with SMTP id b10so2617308wer.31 for ; Fri, 13 Apr 2012 12:56:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=i1cum91kjrX8BZcHPIEDIu9xME+qKwNiRq64WV3TH9E=; b=YWLc16DgAzmvOo4VfNnGfvuK1q0Gs+5Qvf7ooqMNf5fv3PbjtiEV25DWcL+3Ypyh6B 6+Boj6ZKtLjIW4cqGu4OrBixGkNsBVAasPUTf3abW4eMc53YZqh932wj9kz2lTIGpt8Z Rm9KcFEirf2WvQ4NUUE+XYKyhCw/AFFlts+WvYlSuPo4RHpTnvMIOqSN1HT0N9yH/oW6 y+TyA+PlKSC23bLE6l+0ST6UCFYPrksG/pFjexlmZlMqNM6IUYcF5suWM1K25YErbzqR I/EDH18NHlp2Tir0quyHMuuShQ/ANy3/YTe4Ww3BgKsUe+eiWHN/FxUTxix1eNazJuVR xkaw== Received: by 10.180.107.132 with SMTP id hc4mr6640109wib.21.1334346961012; Fri, 13 Apr 2012 12:56:01 -0700 (PDT) Received: from [10.0.9.253] ([212.144.56.68]) by mx.google.com with ESMTPS id ea6sm7044398wib.5.2012.04.13.12.55.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Apr 2012 12:55:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_A161D0BB-38FF-41F2-81E1-587D30425FCA" From: John Bradley In-Reply-To: <59E470B10C4630419ED717AC79FCF9A90741A7@BL2PRD0410MB363.namprd04.prod.outlook.com> Date: Fri, 13 Apr 2012 21:55:40 +0200 Message-Id: <54CAB96A-859B-4CB1-92DB-45359C8DBABA@ve7jtb.com> References: <59E470B10C4630419ED717AC79FCF9A906E74E@CH1PRD0410MB369.namprd04.prod.outlook.com> <4F885680.5090801@mitre.org> <59E470B10C4630419ED717AC79FCF9A90741A7@BL2PRD0410MB363.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnnBZvk0UDw54gid2nGUikLKqjJdLrELYwh8I4dW2Bei2Rl8x3UDayNnKe+I7kNpF9yUsPa Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Fri, 13 Apr 2012 19:56:03 -0000 --Apple-Mail=_A161D0BB-38FF-41F2-81E1-587D30425FCA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Inline. On 2012-04-13, at 9:13 PM, Lewis Adam-CAL022 wrote: > Hi Justin =85 > =20 > In your application, to start things off, you fire off a web browser = to the authorization server's authorization endpoint. The user logs in = to the authorization server through the web browser, approves this copy = of your app, and gets redirected to = "myapp://oauthcallback?code=3Dbasdf132". Your app grabs the "myapp://" = url and plucks the authorization code off the end of it. Your app then = takes that code and sends it in the background to the token endpoint to = exchange for a token. > =20 > this is the part I=92m missing. I understand how to get the = authorization code to the client =85 I think what you=92re saying is = that when the client present the access code to the token endpoint, that = the token endpoint can return either a SAML or JWT token?=20 Yes this is returned as a bearer token in OAuth speak, but the contents = can be JWT or SAML. > Is the token endpoint typically part of the Authorization Server? Is = the type of token returned (SAML/JWT/etc) depending on the = implementation and what is supported by different vendors and open = source, or is this required by the standard? The Token endpoint is part of the Authorization server. The format of the authorization and refresh tokens are not defined in = the OAuth 2.0 spec, other than to treat them as opaque to the client. > OAuth 2.0 doesn=92t really say a whole lot about the actual access = token. Is this all considered out of band from OAuth and a matter of = implementation? Yes, some implementations send SAML tokens to the resource server, some = JWT, and probably most send a proprietary or opaque token to the = resource server which then calls back to a STS like service to = introspect the token. I know Justin has introspection endpoint as part of the MITRE openID = connect implementation. Ping also uses a similar one by default but = can also use structured tokens. > Btw =85 I currently have two OAuth implementations running in the = lab =85 an evaluation copy of PingFederate and an open source stack = (OpenAM). I am with one of the ForgeRock people tomorrow so I will check on what = they are using for access tokens. Both implementations will probably work for what you are trying to do. = I can't speculate on which is best for you at this point. Regards John B. >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A161D0BB-38FF-41F2-81E1-587D30425FCA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Inline.

On 2012-04-13, at 9:13 = PM, Lewis Adam-CAL022 wrote:

Hi Justin = =85
 
In your = application, to start things off, you fire off a web browser to the = authorization server's authorization endpoint. The user logs in to the = authorization server through the web browser, approves this copy of your = app, and gets redirected to "myapp://oauthcallback?code=3Dbasdf132". = Your app grabs the "myapp://" url and plucks the authorization code off = the end of it. Your app then takes that code and sends it in the = background to the token endpoint to exchange for a token.
<acl> this is the part = I=92m missing.  I understand how to get the authorization code to = the client =85  I think what you=92re saying is that when the = client present the access code to the token endpoint, that the token = endpoint can return either a SAML or JWT token?  =

Yes this is = returned as a bearer token in OAuth speak, but the contents can be JWT = or SAML.

Is the token endpoint typically part of the Authorization = Server?  Is the type of token returned (SAML/JWT/etc) depending on = the implementation and what is supported by different vendors and open = source, or is this required by the = standard?

The = Token endpoint is part of the Authorization = server.

The format of the authorization and = refresh tokens are not defined in the OAuth 2.0 spec, other than to = treat them as opaque to the client.

  OAuth 2.0 doesn=92t really say a whole lot about the = actual access token.  Is this all considered out of band from OAuth = and a matter of = implementation?

Yes,  some implementations send SAML tokens to the resource = server, some JWT, and probably most send a proprietary or opaque token = to the resource server which then calls back to a STS like service to = introspect the token.

I know Justin has = introspection endpoint as part of the MITRE openID connect = implementation.   Ping also uses a similar one by default but can = also use structured tokens.

  Btw =85 I currently have two OAuth implementations = running in the lab =85 an evaluation copy of PingFederate and an open = source stack (OpenAM). = </acl>

I am with one of the ForgeRock people tomorrow so I will check on what = they are using for access tokens.

Both = implementations will probably work for what you are trying to do. =  I can't speculate on which is best for you at this = point.


Regards
John = B.


OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_A161D0BB-38FF-41F2-81E1-587D30425FCA-- From romeda@gmail.com Fri Apr 13 15:47:35 2012 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 2CC6011E813A for ; Fri, 13 Apr 2012 15:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.156 X-Spam-Level: X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFq9UiOE+eoo for ; Fri, 13 Apr 2012 15:47:34 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB6611E8135 for ; Fri, 13 Apr 2012 15:47:33 -0700 (PDT) Received: by lbbgf14 with SMTP id gf14so831135lbb.31 for ; Fri, 13 Apr 2012 15:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TnQcct+895cH4eJTs4qh1ZETKCH1Vg+EYrzOxUfjTqI=; b=UOW5SdbHDdY8VtmA8TTx9xoCYH4Pk61DrPwiSg6ZircuR+UsI3MKdv/GnFOSFazGVn pW5OLwb5oX3yKumcqmpM0/b1j5dkao2ZBrXrN8KrumYo7ZLjuGK1ZDkLbmI6I90nBfux 4/kYANbqJ2WCb8RRu90B6KAKs9Dy+IBNlIgSQF1DEUfAHamhL1fNcPNFqmxajcr0HIXR aRaF1oGkYb2YIOC4XwG2btiNb+SZkRzpkuOf1/sVSOLwzfMbzcIMvQh/6DJyfy12+3Xt bLTz7bPeXbK+L970LY9Px2DGFMwdZN+B1ywRaxNwxdqF0H30fny5keobxXJSLnIkKvxZ dI9w== Received: by 10.152.105.241 with SMTP id gp17mr3232235lab.21.1334357252859; Fri, 13 Apr 2012 15:47:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.4.166 with HTTP; Fri, 13 Apr 2012 15:47:12 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436646671B@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4E1F6AAD24975D4BA5B168042967394366465919@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436646671B@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Blaine Cook Date: Fri, 13 Apr 2012 18:47:12 -0400 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=f46d0407152b0f67eb04bd974284 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 13 Apr 2012 22:47:35 -0000 --f46d0407152b0f67eb04bd974284 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 April 2012 12:18, Mike Jones wrote: > Hi Blaine. I must admit, I=E2=80=99m pretty surprised by the tone of yo= ur > reply. I=E2=80=99ll say up front that I have absolutely no problem with = anyone > disagreeing with me on a technical or tactical basis. If you think I=E2= =80=99m > wrong, have at it.**** > > ** ** > > But I am pretty shocked that you would decide to impugn my motives. We= =E2=80=99ve > only met twice and both times I thought we had really useful and producti= ve > discussions about how to move digital identity on the Web forward =E2=80= =93 > something I believe that we=E2=80=99re both passionate about. You don=E2= =80=99t really > know me, though, which is apparent from your remarks below. I believe th= at > those who have worked with me for years would vouch that I am a forthrigh= t > and evenhanded standards participant who listens to all points of view, > tries to build a consensus that works, and produce quality results. > > > I thought about your note overnight and whether I should reply at all. > I=E2=80=99m fine with give and take, but I believe that I need to say tha= t if you > read what you wrote below, I think you=E2=80=99ll agree that the tone you= used was > counter-productive and an apology is in order. > I'm sorry for any offensive comments or tone on my part. I was really taken aback by your comments, because we have had those conversations about Webfinger/SWD, and your technical commentary seemed to me to attempt to intentionally undermine webfinger in ways that I couldn't fathom, given the things we've previously discussed in person. I look forward to moving ahead with future discussions on SWD/Webfinger (frankly, SWD is a better name. ;-) ) in the apps area, and hope that my irate tone hasn't caused any permanent rift. I think we both agree that this work is incredibly important for the future of the web, and I'm hopeful that we can build the best mechanism to provide that future. Best, b. --f46d0407152b0f67eb04bd974284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 April 2012 12:18, Mike Jones <Michael.Jones@microsoft.com> wro= te:

Hi Blaine.=C2=A0 I must a= dmit, I=E2=80=99m pretty surprised by the tone of your reply.=C2=A0 I=E2=80= =99ll say up front that I have absolutely no problem with anyone disagreein= g with me on a technical or tactical basis.=C2=A0 If you think I=E2=80=99m wrong,= have at it.

=C2=A0

But I am pretty shocked t= hat you would decide to impugn my motives.=C2=A0 We=E2=80=99ve only met twi= ce and both times I thought we had really useful and productive discussions about how to move digital identity on the Web forward =E2=80=93 something = I believe that we=E2=80=99re both passionate about.=C2=A0 You don=E2=80=99t= really know me, though, which is apparent from your remarks below.=C2=A0 I= believe that those who have worked with me for years would vouch that I am a forthright and evenhanded standards participant who listens to= all points of view, tries to build a consensus that works, and produce qua= lity results.=C2=A0

<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size= :11pt">=C2=A0

I thought about your note= overnight and whether I should reply at all.=C2=A0 I=E2=80=99m fine with g= ive and take, but I believe that I need to say that if you read what you wrote below, I think you=E2=80=99ll agree that the tone you used was c= ounter-productive and an apology is in order.

=

I'm sorry for any offensive comments or tone on my = part. I was really taken aback by your comments, because we have had those = conversations about Webfinger/SWD, and your technical commentary seemed to = me to attempt to intentionally undermine webfinger in ways that I couldn= 9;t fathom, given the things we've previously discussed in person.

I look forward to moving ahead with future discussions = on SWD/Webfinger (frankly, SWD is a better name. ;-) ) in the apps area, an= d hope that my irate tone hasn't caused any permanent rift. I think we = both agree that this work is incredibly important for the future of the web= , and I'm hopeful that we can build the best mechanism to provide that = future.

Best,

b.
--f46d0407152b0f67eb04bd974284-- From Michael.Jones@microsoft.com Fri Apr 13 15:58:39 2012 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 4566C21F85A3 for ; Fri, 13 Apr 2012 15:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJCVTt73HJp4 for ; Fri, 13 Apr 2012 15:58:38 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id E272E21F85A1 for ; Fri, 13 Apr 2012 15:58:37 -0700 (PDT) Received: from mail112-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Apr 2012 22:58:37 +0000 Received: from mail112-va3 (localhost [127.0.0.1]) by mail112-va3-R.bigfish.com (Postfix) with ESMTP id 263563A0767; Fri, 13 Apr 2012 22:58:37 +0000 (UTC) X-SpamScore: -26 X-BigFish: VS-26(zz9371I1415Jc89bhc857h98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail112-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail112-va3 (localhost.localdomain [127.0.0.1]) by mail112-va3 (MessageSwitch) id 1334357913944336_19679; Fri, 13 Apr 2012 22:58:33 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.253]) by mail112-va3.bigfish.com (Postfix) with ESMTP id DB8914C0059; Fri, 13 Apr 2012 22:58:33 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Apr 2012 22:58:33 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.13]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Fri, 13 Apr 2012 22:58:31 +0000 From: Mike Jones To: Blaine Cook Thread-Topic: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNGJt50G7JnMt5ukqcfN3YYKxyCZaXuy7ggAAOMYCAARDukIAAgzYAgAABQ8A= Date: Fri, 13 Apr 2012 22:58:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664672FD@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4E1F6AAD24975D4BA5B168042967394366465919@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436646671B@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943664672FDTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 13 Apr 2012 22:58:39 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943664672FDTK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEJsYWluZS4gIEkgYXBwcmVjaWF0ZSBpdCwgYW5kIEnigJltIHNvcnJ5IGZvciBhbnkg bWlzc3RhdGVtZW50cyBpbiBteSBub3RlLiAgWWVzLCB3ZSBib3RoIGFncmVlIG9uIGhvdyBpbXBv cnRhbnQgdGhpcyBhbmQgSSBsb29rIGZvcndhcmQgdG8gd29ya2luZyB3aXRoIHlvdSB0byBtYWtl IGl0IGhhcHBlbiENCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEJlc3Qgd2lzaGVzLA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJv bTogQmxhaW5lIENvb2sgW21haWx0bzpyb21lZGFAZ21haWwuY29tXQ0KU2VudDogRnJpZGF5LCBB cHJpbCAxMywgMjAxMiAzOjQ3IFBNDQpUbzogTWlrZSBKb25lcw0KQ2M6IG9hdXRoQGlldGYub3Jn IFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBXZWIgRmluZ2VyIHZzLiBTaW1wbGUgV2ViIERp c2NvdmVyeSAoU1dEKQ0KDQpPbiAxMyBBcHJpbCAyMDEyIDEyOjE4LCBNaWtlIEpvbmVzIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT4+IHdyb3RlOg0KSGkgQmxhaW5lLiAgSSBtdXN0IGFkbWl0LCBJ4oCZbSBwcmV0dHkgc3VycHJp c2VkIGJ5IHRoZSB0b25lIG9mIHlvdXIgcmVwbHkuICBJ4oCZbGwgc2F5IHVwIGZyb250IHRoYXQg SSBoYXZlIGFic29sdXRlbHkgbm8gcHJvYmxlbSB3aXRoIGFueW9uZSBkaXNhZ3JlZWluZyB3aXRo IG1lIG9uIGEgdGVjaG5pY2FsIG9yIHRhY3RpY2FsIGJhc2lzLiAgSWYgeW91IHRoaW5rIEnigJlt IHdyb25nLCBoYXZlIGF0IGl0Lg0KDQpCdXQgSSBhbSBwcmV0dHkgc2hvY2tlZCB0aGF0IHlvdSB3 b3VsZCBkZWNpZGUgdG8gaW1wdWduIG15IG1vdGl2ZXMuICBXZeKAmXZlIG9ubHkgbWV0IHR3aWNl IGFuZCBib3RoIHRpbWVzIEkgdGhvdWdodCB3ZSBoYWQgcmVhbGx5IHVzZWZ1bCBhbmQgcHJvZHVj dGl2ZSBkaXNjdXNzaW9ucyBhYm91dCBob3cgdG8gbW92ZSBkaWdpdGFsIGlkZW50aXR5IG9uIHRo ZSBXZWIgZm9yd2FyZCDigJMgc29tZXRoaW5nIEkgYmVsaWV2ZSB0aGF0IHdl4oCZcmUgYm90aCBw YXNzaW9uYXRlIGFib3V0LiAgWW91IGRvbuKAmXQgcmVhbGx5IGtub3cgbWUsIHRob3VnaCwgd2hp Y2ggaXMgYXBwYXJlbnQgZnJvbSB5b3VyIHJlbWFya3MgYmVsb3cuICBJIGJlbGlldmUgdGhhdCB0 aG9zZSB3aG8gaGF2ZSB3b3JrZWQgd2l0aCBtZSBmb3IgeWVhcnMgd291bGQgdm91Y2ggdGhhdCBJ IGFtIGEgZm9ydGhyaWdodCBhbmQgZXZlbmhhbmRlZCBzdGFuZGFyZHMgcGFydGljaXBhbnQgd2hv IGxpc3RlbnMgdG8gYWxsIHBvaW50cyBvZiB2aWV3LCB0cmllcyB0byBidWlsZCBhIGNvbnNlbnN1 cyB0aGF0IHdvcmtzLCBhbmQgcHJvZHVjZSBxdWFsaXR5IHJlc3VsdHMuDQoNCkkgdGhvdWdodCBh Ym91dCB5b3VyIG5vdGUgb3Zlcm5pZ2h0IGFuZCB3aGV0aGVyIEkgc2hvdWxkIHJlcGx5IGF0IGFs bC4gIEnigJltIGZpbmUgd2l0aCBnaXZlIGFuZCB0YWtlLCBidXQgSSBiZWxpZXZlIHRoYXQgSSBu ZWVkIHRvIHNheSB0aGF0IGlmIHlvdSByZWFkIHdoYXQgeW91IHdyb3RlIGJlbG93LCBJIHRoaW5r IHlvdeKAmWxsIGFncmVlIHRoYXQgdGhlIHRvbmUgeW91IHVzZWQgd2FzIGNvdW50ZXItcHJvZHVj dGl2ZSBhbmQgYW4gYXBvbG9neSBpcyBpbiBvcmRlci4NCg0KSSdtIHNvcnJ5IGZvciBhbnkgb2Zm ZW5zaXZlIGNvbW1lbnRzIG9yIHRvbmUgb24gbXkgcGFydC4gSSB3YXMgcmVhbGx5IHRha2VuIGFi YWNrIGJ5IHlvdXIgY29tbWVudHMsIGJlY2F1c2Ugd2UgaGF2ZSBoYWQgdGhvc2UgY29udmVyc2F0 aW9ucyBhYm91dCBXZWJmaW5nZXIvU1dELCBhbmQgeW91ciB0ZWNobmljYWwgY29tbWVudGFyeSBz ZWVtZWQgdG8gbWUgdG8gYXR0ZW1wdCB0byBpbnRlbnRpb25hbGx5IHVuZGVybWluZSB3ZWJmaW5n ZXIgaW4gd2F5cyB0aGF0IEkgY291bGRuJ3QgZmF0aG9tLCBnaXZlbiB0aGUgdGhpbmdzIHdlJ3Zl IHByZXZpb3VzbHkgZGlzY3Vzc2VkIGluIHBlcnNvbi4NCg0KSSBsb29rIGZvcndhcmQgdG8gbW92 aW5nIGFoZWFkIHdpdGggZnV0dXJlIGRpc2N1c3Npb25zIG9uIFNXRC9XZWJmaW5nZXIgKGZyYW5r bHksIFNXRCBpcyBhIGJldHRlciBuYW1lLiA7LSkgKSBpbiB0aGUgYXBwcyBhcmVhLCBhbmQgaG9w ZSB0aGF0IG15IGlyYXRlIHRvbmUgaGFzbid0IGNhdXNlZCBhbnkgcGVybWFuZW50IHJpZnQuIEkg dGhpbmsgd2UgYm90aCBhZ3JlZSB0aGF0IHRoaXMgd29yayBpcyBpbmNyZWRpYmx5IGltcG9ydGFu dCBmb3IgdGhlIGZ1dHVyZSBvZiB0aGUgd2ViLCBhbmQgSSdtIGhvcGVmdWwgdGhhdCB3ZSBjYW4g YnVpbGQgdGhlIGJlc3QgbWVjaGFuaXNtIHRvIHByb3ZpZGUgdGhhdCBmdXR1cmUuDQoNCkJlc3Qs DQoNCmIuDQo= --_000_4E1F6AAD24975D4BA5B1680429673943664672FDTK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+VGhhbmtzIEJsYWluZS4m bmJzcDsgSSBhcHByZWNpYXRlIGl0LCBhbmQgSeKAmW0gc29ycnkgZm9yIGFueSBtaXNzdGF0ZW1l bnRzIGluIG15IG5vdGUuJm5ic3A7IFllcywgd2UgYm90aCBhZ3JlZSBvbiBob3cgaW1wb3J0YW50 IHRoaXMgYW5kIEkgbG9vayBmb3J3YXJkIHRvIHdvcmtpbmcgd2l0aA0KIHlvdSB0byBtYWtlIGl0 IGhhcHBlbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBC ZXN0IHdpc2hlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2 MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IEJsYWluZSBDb29rIFttYWlsdG86cm9tZWRhQGdtYWlsLmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDEzLCAyMDEyIDM6NDcgUE08YnI+DQo8Yj5U bzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnIFdHPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFdlYiBGaW5nZXIgdnMuIFNpbXBsZSBXZWIg RGlzY292ZXJ5IChTV0QpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMyBBcHJp bCAyMDEyIDEyOjE4LCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBCbGFpbmUuJm5ic3A7IEkgbXVzdCBhZG1pdCwgSeKAmW0gcHJldHR5IHN1cnByaXNl ZCBieSB0aGUgdG9uZSBvZiB5b3VyIHJlcGx5LiZuYnNwOyBJ4oCZbGwgc2F5IHVwIGZyb250IHRo YXQNCiBJIGhhdmUgYWJzb2x1dGVseSBubyBwcm9ibGVtIHdpdGggYW55b25lIGRpc2FncmVlaW5n IHdpdGggbWUgb24gYSB0ZWNobmljYWwgb3IgdGFjdGljYWwgYmFzaXMuJm5ic3A7IElmIHlvdSB0 aGluayBJ4oCZbSB3cm9uZywgaGF2ZSBhdCBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgSSBhbSBwcmV0 dHkgc2hvY2tlZCB0aGF0IHlvdSB3b3VsZCBkZWNpZGUgdG8gaW1wdWduIG15IG1vdGl2ZXMuJm5i c3A7IFdl4oCZdmUgb25seSBtZXQgdHdpY2UgYW5kIGJvdGgNCiB0aW1lcyBJIHRob3VnaHQgd2Ug aGFkIHJlYWxseSB1c2VmdWwgYW5kIHByb2R1Y3RpdmUgZGlzY3Vzc2lvbnMgYWJvdXQgaG93IHRv IG1vdmUgZGlnaXRhbCBpZGVudGl0eSBvbiB0aGUgV2ViIGZvcndhcmQg4oCTIHNvbWV0aGluZyBJ IGJlbGlldmUgdGhhdCB3ZeKAmXJlIGJvdGggcGFzc2lvbmF0ZSBhYm91dC4mbmJzcDsgWW91IGRv buKAmXQgcmVhbGx5IGtub3cgbWUsIHRob3VnaCwgd2hpY2ggaXMgYXBwYXJlbnQgZnJvbSB5b3Vy IHJlbWFya3MgYmVsb3cuJm5ic3A7IEkgYmVsaWV2ZQ0KIHRoYXQgdGhvc2Ugd2hvIGhhdmUgd29y a2VkIHdpdGggbWUgZm9yIHllYXJzIHdvdWxkIHZvdWNoIHRoYXQgSSBhbSBhIGZvcnRocmlnaHQg YW5kIGV2ZW5oYW5kZWQgc3RhbmRhcmRzIHBhcnRpY2lwYW50IHdobyBsaXN0ZW5zIHRvIGFsbCBw b2ludHMgb2YgdmlldywgdHJpZXMgdG8gYnVpbGQgYSBjb25zZW5zdXMgdGhhdCB3b3JrcywgYW5k IHByb2R1Y2UgcXVhbGl0eSByZXN1bHRzLjwvc3Bhbj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhvdWdodCBhYm91dCB5 b3VyIG5vdGUgb3Zlcm5pZ2h0IGFuZCB3aGV0aGVyIEkgc2hvdWxkIHJlcGx5IGF0IGFsbC4mbmJz cDsgSeKAmW0gZmluZSB3aXRoIGdpdmUgYW5kIHRha2UsDQogYnV0IEkgYmVsaWV2ZSB0aGF0IEkg bmVlZCB0byBzYXkgdGhhdCBpZiB5b3UgcmVhZCB3aGF0IHlvdSB3cm90ZSBiZWxvdywgSSB0aGlu ayB5b3XigJlsbCBhZ3JlZSB0aGF0IHRoZSB0b25lIHlvdSB1c2VkIHdhcyBjb3VudGVyLXByb2R1 Y3RpdmUgYW5kIGFuIGFwb2xvZ3kgaXMgaW4gb3JkZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20g c29ycnkgZm9yIGFueSBvZmZlbnNpdmUgY29tbWVudHMgb3IgdG9uZSBvbiBteSBwYXJ0LiBJIHdh cyByZWFsbHkgdGFrZW4gYWJhY2sgYnkgeW91ciBjb21tZW50cywgYmVjYXVzZSB3ZSBoYXZlIGhh ZCB0aG9zZSBjb252ZXJzYXRpb25zIGFib3V0IFdlYmZpbmdlci9TV0QsIGFuZCB5b3VyIHRlY2hu aWNhbCBjb21tZW50YXJ5IHNlZW1lZCB0byBtZSB0byBhdHRlbXB0IHRvIGludGVudGlvbmFsbHkg dW5kZXJtaW5lDQogd2ViZmluZ2VyIGluIHdheXMgdGhhdCBJIGNvdWxkbid0IGZhdGhvbSwgZ2l2 ZW4gdGhlIHRoaW5ncyB3ZSd2ZSBwcmV2aW91c2x5IGRpc2N1c3NlZCBpbiBwZXJzb24uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgbG9vayBm b3J3YXJkIHRvIG1vdmluZyBhaGVhZCB3aXRoIGZ1dHVyZSBkaXNjdXNzaW9ucyBvbiBTV0QvV2Vi ZmluZ2VyIChmcmFua2x5LCBTV0QgaXMgYSBiZXR0ZXIgbmFtZS4gOy0pICkgaW4gdGhlIGFwcHMg YXJlYSwgYW5kIGhvcGUgdGhhdCBteSBpcmF0ZSB0b25lIGhhc24ndCBjYXVzZWQgYW55IHBlcm1h bmVudCByaWZ0LiBJIHRoaW5rIHdlIGJvdGggYWdyZWUgdGhhdCB0aGlzIHdvcmsgaXMgaW5jcmVk aWJseQ0KIGltcG9ydGFudCBmb3IgdGhlIGZ1dHVyZSBvZiB0aGUgd2ViLCBhbmQgSSdtIGhvcGVm dWwgdGhhdCB3ZSBjYW4gYnVpbGQgdGhlIGJlc3QgbWVjaGFuaXNtIHRvIHByb3ZpZGUgdGhhdCBm dXR1cmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B1680429673943664672FDTK5EX14MBXC283r_-- From eve@xmlgrrl.com Fri Apr 13 18:30:03 2012 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 B723421F8533 for ; Fri, 13 Apr 2012 18:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUW3+2u12O97 for ; Fri, 13 Apr 2012 18:30:03 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3821F8526 for ; Fri, 13 Apr 2012 18:29:30 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q3E1TQHx022801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Apr 2012 18:29:27 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> Date: Fri, 13 Apr 2012 18:29:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3E72A308-75EE-4F5C-96CC-A51F0B81106A@xmlgrrl.com> References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1257) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration 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: Sat, 14 Apr 2012 01:30:03 -0000 Hi Hannes-- That's kind of a cool idea. You're right that it's a "client = account" of sorts. At least worth exploring, I'd say, unless a SCIM = expert pipes up with a reason why not. Eve On 13 Apr 2012, at 7:36 AM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > at the IETF#83 OAuth working group meeting we had some confusion about = the Dynamic Client Registration and the Simple Web Discovery item. I = just listened to the audio recording again.=20 >=20 > With the ongoing mailing list discussion regarding WebFinger vs. = Simple Web Discovery I hope that folks had a chance to look at the = documents again and so the confusion of some got resolved. =20 >=20 > I believe the proposed new charter item is sufficiently clear with = regard to the scope of the work. Right?=20 > Here is the item again: > " > Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the = IESG for consideration as a Proposed Standard >=20 > [Starting point for the work will be=20 > http://tools.ietf.org/html/draft-hardjono-oauth-dynreg > ]=20 > " >=20 > Of course there there is a relationship between Simple Web Discovery = (or WebFinger) and the dynamic client registration since the client = first needs to discover the client registration endpoint at the = authorization server before interacting with it.=20 >=20 > Now, one thing that just came to my mind when looking again at = draft-hardjono-oauth-dynreq was the following: Could the Client = Registration Request and Response protocol exchange could become a = profile of the SCIM protocol? In some sense this exchange is nothing = else than provisioning an account at the Authorization Server (along = with some meta-data). >=20 > Is this too far fetched?=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From hannes.tschofenig@nsn.com Sat Apr 14 05:25:56 2012 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 3A5E821F8610 for ; Sat, 14 Apr 2012 05:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.684 X-Spam-Level: X-Spam-Status: No, score=-105.684 tagged_above=-999 required=5 tests=[AWL=0.914, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJz185ua7YXs for ; Sat, 14 Apr 2012 05:25:55 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C903521F860F for ; Sat, 14 Apr 2012 05:25:39 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q3ECPZYA005313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Apr 2012 14:25:35 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q3ECPXtU007110; Sat, 14 Apr 2012 14:25:33 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 Apr 2012 14:25:03 +0200 Received: from 10.159.32.12 ([10.159.32.12]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) with Microsoft Exchange Server HTTP-DAV ; Sat, 14 Apr 2012 12:25:02 +0000 MIME-Version: 1.0 Message-ID: <4ad901cd1a39$9dd5cdba$0c209f0a@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [OAUTH-WG] Updated Charter to the IESG (this weekend) Thread-Index: Ac0aOZ3VpnOPpGHwQz+aI0fW6un0pQ== Date: Sat, 14 Apr 2012 15:28:00 +0300 To: "ext Justin Richer" , "Mike Jones" Content-Type: multipart/alternative; boundary="_9F925CBF-FE52-851F-4801-94313BBF20E3_"; charset="iso-8859-1" X-OriginalArrivalTime: 14 Apr 2012 12:25:03.0933 (UTC) FILETIME=[9E9056D0:01CD1A39] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 19214 X-purgate-ID: 151667::1334406335-00007415-E4F67D7D/0-0/0-0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Sat, 14 Apr 2012 12:25:56 -0000 --_9F925CBF-FE52-851F-4801-94313BBF20E3_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi Mike, Hi Justin, it would be important to point to a document or some other write-up so that= everyone in the group understands the scope of the work you are proposing = to do. Ciao Hannes Sent from my Windows Phone -----Original Message----- From: ext Justin Richer Sent: 4/13/2012 9:32 PM To: Mike Jones Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) OK, but with SWD and discovery off the table, can this now be considered=20 to be within that manageable number instead? -- Justin On 04/13/2012 01:10 PM, Mike Jones wrote: > Yes, there was an explicit decision in that regard. My sense was that th= e WG did think they're important but they only wanted to take on a manageab= le number of tasks at once. > > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Justin Richer > Sent: Friday, April 13, 2012 10:02 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) > > Did the "Introspection Endpoint" or "Methods for connecting a PR to an AS= " get dropped? There seemed to be interest in the list in coming up with a = generally applicable scheme, or set of schemes, to do this, and there are c= ertainly no shortage of starting points. Both AOL and Ping have their own t= oken introspection drafts that got put to the list, we've developed our own= internal approach here, UMA has an alternative approach, and OpenID Connec= t has invented its own approach for ID Tokens. > > I just want to make sure that this was an explicit decision of it being o= ut of scope here and not an inadvertent omission. > > -- Justin > > On 04/12/2012 06:55 AM, Hannes Tschofenig wrote: >> Hey guys >> >> based on the discussion before, during, and after the Paris IETF meeting= I am going to send the following updated charter / milestones to the IESG. >> Please have a quick look (till the end of the week) to double-check the = content (particularly the suggested milestone dates): >> >> ---------- >> >> >> Web Authorization Protocol (oauth) >> >> Description of Working Group >> >> The Web Authorization (OAuth) protocol allows a user to grant a >> third-party Web site or application access to the user's protected >> resources, without necessarily revealing their long-term credentials, >> or even their identity. For example, a photo-sharing site that >> supports OAuth could allow its users to use a third-party printing Web >> site to print their private pictures, without allowing the printing >> site to gain full control of the user's account and without having the >> user sharing his or her photo-sharing sites' long-term credential with >> the printing site. >> >> The OAuth protocol suite encompasses >> * a procedure for allowing a client to discover a resource server, >> * a protocol for obtaining authorization tokens from an authorization >> server with the resource owner's consent, >> * protocols for presenting these authorization tokens to protected >> resources for access to a resource, and >> * consequently for sharing data in a security and privacy respective way= . >> >> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, >> was published as an informational document (RFC 5849). With the >> completion of OAuth 1.0 the working group started their work on OAuth >> 2.0 to incorporate implementation experience with version 1.0, >> additional use cases, and various other security, readability, and >> interoperability improvements. An extensive security analysis was >> conducted and the result is available as a stand-alone document >> offering guidance for audiences beyond the community of protocol impleme= nters. >> >> The working group also developed security schemes for presenting >> authorization tokens to access a protected resource. This led to the >> publication of the bearer token as well as the message authentication >> code (MAC) access authentication specification. >> >> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH >> token with the SAML 2.0 bearer assertion profile. This offers >> interworking with existing identity management solutions, in particular = SAML based deployments. >> >> OAuth has enjoyed widespread adoption by the Internet application >> service provider community. To build on this success we aim for >> nothing more than to make OAuth the authorization framework of choice >> for any Internet protocol. Consequently, the ongoing standardization >> effort within the OAuth working group is focused on enhancing >> interoperability of OAuth deployments. While the core OAuth >> specification truly is an important building block it relies on other >> specifications in order to claim completeness. Luckily, these >> components already exist and have been deployed on the Internet. Through= the IETF standards process they will be improved in quality and will under= go a rigorous review process. >> >> Goals and Milestones >> >> [Editor's Note: Here are the completed items.] >> >> Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a >> working group item Done Submit 'HTTP Authentication: MAC >> Authentication' as a working group item Done Submit 'The OAuth 2.0 >> Protocol: Bearer Tokens' to the IESG for consideration as a Proposed >> Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the >> IESG for consideration as a Proposed Standard >> >> [Editor's Note: Finishing existing work. Double-check the proposed >> dates - are they realistic?] >> >> May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' >> to the IESG for consideration as a Proposed Standard May 2012 Submit >> 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a >> Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace for >> OAuth' to the IESG for consideration as a Proposed Standard May 2012 >> Submit 'OAuth 2.0 Threat Model and Security Considerations' to the >> IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP >> Authentication: MAC Authentication' to the IESG for consideration as a >> Proposed Standard >> >> [Editor's Note: New work for the group] >> >> Nov. 2012 Submit 'Token Revocation' to the IESG for consideration as >> a Proposed Standard >> >> [Starting point for the work will be >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] >> >> Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as >> an Informational RFC >> >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] >> >> Jan. 2013 Submit 'Simple Web Discovery' to the IESG for consideration >> as a Proposed Standard >> >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-jones-simple-web-discovery] >> >> Mar. 2013 Submit 'JSON Web Token (JWT)' to the IESG for consideration >> as a Proposed Standard >> >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-jones-json-web-token] >> >> Mar. 2013 Submit 'JSON Web Token (JWT) Bearer Token Profiles for >> OAuth 2.0' to the IESG for consideration as a Proposed Standard >> >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] >> >> Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the >> IESG for consideration as a Proposed Standard >> >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] >> >> >> _______________________________________________ >> 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 --_9F925CBF-FE52-851F-4801-94313BBF20E3_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Hi Mike, Hi Justin,

it would be important to po= int to a document or some other write-up so that everyone in the group unde= rstands the scope of the work you are proposing to do.

Ciao
Hanne= s

Sent from my Windows Phone
From: ext Just= in Richer
Sent: 4/13/2012 9:32 PM
To: Mike = Jones
Cc: oauth@ietf.org WG
Subject: Re: [O= AUTH-WG] Updated Charter to the IESG (this weekend)

OK, but w= ith SWD and discovery off the table, can this now be considered
to be w= ithin that manageable number instead?

  -- Justin

On 04/= 13/2012 01:10 PM, Mike Jones wrote:
> Yes, there was an explicit deci= sion in that regard.  My sense was that the WG did think they're impor= tant but they only wanted to take on a manageable number of tasks at once.<= br>>
> -- Mike
>
> -----Original Message-----
&= gt; From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Justin Richer
> Sent: Friday, April 13, 2012 10:02 AM
> To: = Hannes Tschofenig
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH= -WG] Updated Charter to the IESG (this weekend)
>
> Did the "In= trospection Endpoint" or "Methods for connecting a PR to an AS" get dropped= ? There seemed to be interest in the list in coming up with a generally app= licable scheme, or set of schemes, to do this, and there are certainly no s= hortage of starting points. Both AOL and Ping have their own token introspe= ction drafts that got put to the list, we've developed our own internal app= roach here, UMA has an alternative approach, and OpenID Connect has invente= d its own approach for ID Tokens.
>
> I just want to make sure = that this was an explicit decision of it being out of scope here and not an= inadvertent omission.
>
>    -- Justin
><= br>> On 04/12/2012 06:55 AM, Hannes Tschofenig wrote:
>> Hey gu= ys
>>
>> based on the discussion before, during, and afte= r the Paris IETF meeting I am going to send the following updated charter /= milestones to the IESG.
>> Please have a quick look (till the end= of the week) to double-check the content (particularly the suggested miles= tone dates):
>>
>> ----------
>>
>>
= >> Web Authorization Protocol (oauth)
>>
>> Descrip= tion of Working Group
>>
>> The Web Authorization (OAuth)= protocol allows a user to grant a
>> third-party Web site or appl= ication access to the user's protected
>> resources, without neces= sarily revealing their long-term credentials,
>> or even their ide= ntity. For example, a photo-sharing site that
>> supports OAuth co= uld allow its users to use a third-party printing Web
>> site to p= rint their private pictures, without allowing the printing
>> site= to gain full control of the user's account and without having the
>&= gt; user sharing his or her photo-sharing sites' long-term credential with<= br>>> the printing site.
>>
>> The OAuth protocol s= uite encompasses
>> * a procedure for allowing a client to discove= r a resource server,
>> * a protocol for obtaining authorization t= okens from an authorization
>> server with the resource owner's co= nsent,
>> * protocols for presenting these authorization tokens to= protected
>> resources for access to a resource, and
>> = * consequently for sharing data in a security and privacy respective way.>>
>> In April 2010 the OAuth 1.0 specification, documenti= ng pre-IETF work,
>> was published as an informational document (R= FC 5849). With the
>> completion of OAuth 1.0 the working group st= arted their work on OAuth
>> 2.0 to incorporate implementation exp= erience with version 1.0,
>> additional use cases, and various oth= er security, readability, and
>> interoperability improvements. An= extensive security analysis was
>> conducted and the result is av= ailable as a stand-alone document
>> offering guidance for audienc= es beyond the community of protocol implementers.
>>
>> T= he working group also developed security schemes for presenting
>>= authorization tokens to access a protected resource. This led to the
&g= t;> publication of the bearer token as well as the message authenticatio= n
>> code (MAC) access authentication specification.
>>>> OAuth 2.0 added the ability to trade a SAML assertion against an= OAUTH
>> token with the SAML 2.0 bearer assertion profile.  = This offers
>> interworking with existing identity management solu= tions, in particular SAML based deployments.
>>
>> OAuth = has enjoyed widespread adoption by the Internet application
>> ser= vice provider community. To build on this success we aim for
>> no= thing more than to make OAuth the authorization framework of choice
>= > for any Internet protocol. Consequently, the ongoing standardization>> effort within the OAuth working group is focused on enhancing>> interoperability of OAuth deployments. While the core OAuth
&g= t;> specification truly is an important building block it relies on othe= r
>> specifications in order to claim completeness. Luckily, these=
>> components already exist and have been deployed on the Interne= t. Through the IETF standards process they will be improved in quality and = will undergo a rigorous review process.
>>
>> Goals and M= ilestones
>>
>> [Editor's Note: Here are the completed it= ems.]
>>
>> Done  Submit 'OAuth 2.0 Threat Model and= Security Considerations' as a
>> working group item Done  Su= bmit 'HTTP Authentication: MAC
>> Authentication' as a working gro= up item Done  Submit 'The OAuth 2.0
>> Protocol: Bearer Token= s' to the IESG for consideration as a Proposed
>> Standard Done&nb= sp; Submit 'The OAuth 2.0 Authorization Protocol' to the
>> IESG f= or consideration as a Proposed Standard
>>
>> [Editor's N= ote: Finishing existing work. Double-check the proposed
>> dates -= are they realistic?]
>>
>> May  2012  Submit '= SAML 2.0 Bearer Assertion Profiles for OAuth 2.0'
>> to the IESG f= or consideration as a Proposed Standard May  2012  Submit
>= > 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a
&g= t;> Proposed Standard May  2012  Submit 'An IETF URN Sub-Names= pace for
>> OAuth' to the IESG for consideration as a Proposed Sta= ndard May  2012
>> Submit 'OAuth 2.0 Threat Model and Securit= y Considerations' to the
>> IESG for consideration as an Informati= onal RFC Dec. 2012  Submit 'HTTP
>> Authentication: MAC Authe= ntication' to the IESG for consideration as a
>> Proposed Standard=
>>
>> [Editor's Note: New work for the group]
>>= ;
>> Nov. 2012  Submit 'Token Revocation' to the IESG for con= sideration as
>> a Proposed Standard
>>
>> [Star= ting point for the work will be
>> http://datatracker.ietf.org/doc= /draft-lodderstedt-oauth-revocation/]
>>
>> Dec. 2012&nbs= p; Submit 'OAuth Use Cases' to the IESG for consideration as
>> an= Informational RFC
>>
>> [Starting point for the work wil= l be
>> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]<= br>>>
>> Jan. 2013  Submit 'Simple Web Discovery' to th= e IESG for consideration
>> as a Proposed Standard
>>
= >> [Starting point for the work will be
>> http://tools.ietf= .org/html/draft-jones-simple-web-discovery]
>>
>> Mar. 20= 13  Submit 'JSON Web Token (JWT)' to the IESG for consideration
>= ;> as a Proposed Standard
>>
>> [Starting point for th= e work will be
>> http://tools.ietf.org/html/draft-jones-json-web-= token]
>>
>> Mar. 2013  Submit 'JSON Web Token (JWT)= Bearer Token Profiles for
>> OAuth 2.0' to the IESG for considera= tion as a Proposed Standard
>>
>> [Starting point for the= work will be
>> http://tools.ietf.org/html/draft-jones-oauth-jwt-= bearer]
>>
>> Jul. 2013  Submit 'OAuth Dynamic Clien= t Registration Protocol' to the
>> IESG for consideration as a Pro= posed Standard
>>
>> [Starting point for the work will be=
>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
>= ;>
>>
>> _____________________________________________= __
>> OAuth mailing list
>> OAuth@ietf.org
>> ht= tps://www.ietf.org/mailman/listinfo/oauth
> _________________________= ______________________
> OAuth mailing list
> OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
>
>

__= _____________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --_9F925CBF-FE52-851F-4801-94313BBF20E3_-- From ve7jtb@ve7jtb.com Sat Apr 14 07:25:19 2012 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 44A4821F85E3 for ; Sat, 14 Apr 2012 07:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veVb4maaY6H5 for ; Sat, 14 Apr 2012 07:25:18 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E31D821F85D7 for ; Sat, 14 Apr 2012 07:25:17 -0700 (PDT) Received: by werb10 with SMTP id b10so2999602wer.31 for ; Sat, 14 Apr 2012 07:25:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=NVDNiM8WfYOavWRaoDWPn+pIV6vlXWzvyCmKffJ6shQ=; b=SgPBGBJiXpl2yPxuZIU5NVatIP3RwdnNjdqPWl89eUjmmncNJKdr2S5hGs+RYHUs5T 6i1lcFTGhjUnZ9zs5LM2N80kHFboMZee+puX0TlchAJW5bz8KmG72sxnz9FIOJNL0o8s snxPXWkSjazepuTuJ2Ou5FoKmYdooVFww7/qeSsxIqIYZrATGYSBpSbX+2ezNT6hdgNm UAjyX5QGHtDaCnL38SLTEmXu1arA3efihvbErMWv+OICWKG6/wDeWz4zIefQWGNeXqx4 +xi0Wfi7PHjfMk41y9qRQXgGaqe32H+d0FlAm8PJQv24+xgqEJWNedQSeHxc/naSzWmh QLPw== Received: by 10.216.135.69 with SMTP id t47mr3038935wei.85.1334413516853; Sat, 14 Apr 2012 07:25:16 -0700 (PDT) Received: from [10.38.90.169] (ip-109-43-0-41.web.vodafone.de. [109.43.0.41]) by mx.google.com with ESMTPS id fz9sm4770809wib.3.2012.04.14.07.25.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Apr 2012 07:25:14 -0700 (PDT) References: <4ad901cd1a39$9dd5cdba$0c209f0a@nsnintra.net> In-Reply-To: <4ad901cd1a39$9dd5cdba$0c209f0a@nsnintra.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-99CFC03B-3D32-4BFC-999E-DCEA4040E00B; protocol="application/pkcs7-signature" Message-Id: <330ED93F-87B0-4225-A6C8-100F5FEE450C@ve7jtb.com> X-Mailer: iPhone Mail (9B179) From: John Bradley Date: Sat, 14 Apr 2012 16:25:15 +0200 To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Gm-Message-State: ALoCoQlLBvCPV1juPSejr58cEiE5x/RMT+m/CZyO9ygvLTWUHL9mA86BNpLi8DRVdOOTT5oduhtZ Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Sat, 14 Apr 2012 14:25:19 -0000 --Apple-Mail-99CFC03B-3D32-4BFC-999E-DCEA4040E00B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There is a Ping document. I was talking to openAM/ForgeRock today about a s= imilar endpoint they are working on. =20 Justin can submit his and I will look for the others.=20 John B.=20 Sent from my iPhone On 2012-04-14, at 2:28 PM, "Tschofenig, Hannes (NSN - FI/Espoo)" wrote: >=20 > OK, but --Apple-Mail-99CFC03B-3D32-4BFC-999E-DCEA4040E00B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTQxNDI1MThaMCMGCSqGSIb3DQEJBDEWBBTNQbRN uuaSofwYl/CN93av0znwHjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQAWDA6sQ3AUYyHYCCKeSkfkkZiJKypaEz7Gu21f vixnnpEQUOEj0gRb9lKGP2JkCLVzmoo5cKlG/ZoYZza3G3VDSYPa/qoreQgk8DAR5Xe6C8SB+/X0 dWPVVCYAdnBEggPN2cHUni8MGJQI4lgWH6AvqpTuOE7Pm7AdqHmJkRd9V2QO/iWjyrfuu+m6sq1X T2ewEM58Q7Eyu9KVWHqSpnI1M/uXDgLCMF9mv6GlEliPdstDJly5snTYQOF6YuPYY94SrikLlPNp lQQRpOrZ754h0g0Kz4uySXbbb78JUkBrRZZDdsrhncl9FMS7AP1PBwTXEv6c5wgol2ePwGbIJYg2 AAAAAAAA --Apple-Mail-99CFC03B-3D32-4BFC-999E-DCEA4040E00B-- From wmills@yahoo-inc.com Sat Apr 14 09:01:15 2012 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 DA33221F85EF for ; Sat, 14 Apr 2012 09:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.815 X-Spam-Level: X-Spam-Status: No, score=-16.815 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqSoqAZiRnN6 for ; Sat, 14 Apr 2012 09:01:15 -0700 (PDT) Received: from nm12-vm2.bullet.mail.ne1.yahoo.com (nm12-vm2.bullet.mail.ne1.yahoo.com [98.138.91.88]) by ietfa.amsl.com (Postfix) with SMTP id C32D021F84D2 for ; Sat, 14 Apr 2012 09:01:14 -0700 (PDT) Received: from [98.138.90.54] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 14 Apr 2012 16:01:05 -0000 Received: from [98.138.89.246] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 14 Apr 2012 16:01:05 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 14 Apr 2012 16:01:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 603772.9311.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 10149 invoked by uid 60001); 14 Apr 2012 16:01:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334419265; bh=V8lws0wTMNOD39J3Qfk8/foKT2KdsZU244UjvBdw2vw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EIZ86n0d3ShHIEF4OKv2rkm+3KvdtoXf1g3pejgNSjaxUIBjwMHBz0gZ6hAg58xHReKWo3gG1CJxwC0ZKDMc/8UdciMehINFRye5inQE2EiXkBqkIL/om39XCdRJwCiQ5G5DiE9r94I+2t3HA9bZ3qlkIzt5Sz76KB/NoxnuX6o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=j2s3tSqXjnAWDMWBRnLCQpR8wmVZSH3tpdBiAct0hMXiUzd43KDf6JKLm9+Pnunz32ij6vFCYWi+vfWe3iYgQSfxXHHBOXl6ERKtllGIphB4mIxecoiEQdtEr9mRnQiGeKZEfPRFnEyq4UDYMjR0oh+0OeSjIEkS1CUAISQIJ98=; X-YMail-OSG: OklQW10VM1lyuOatjzcM2PndxUmNrpaFRNiSh93Jw2wH9pJ 7qJjlIKtSYZDiAVhn8ixPjOQy8d2BpUujTpMZds3.yrOumFCLkbc0in_p56w Itt6Z_tCXgcJyP70ylZNYwLFbSfhON1L7MyXSR3nInktHH39geu1OHCWjigq XlwF4DlBvPPhO92E_5cT.Jjkh1.4K8gKXDT8f68LSOzf7f0BLjP8f.gcPieA 1fDy7yw.qN2763Y5ZES9G8iHSaJqgy7ehpYCZF9X5iAYh92nPbVx6cRRIAjQ xqivOYUDbLn48vaj.trDM58.THcNzW2RWXMTv28g78eJBO4uZ57dQbTEfqSn S0FoFUpnpOArkuLsrVN0gqrTnKe3cEhDaYvXlnAsDtSkYpBhBecYHnco3z5U SOntdinVH3EmOLtX.u1gLXTQ8sBmec68xtD4E.gtyn99Yftkea_K_Dpc9..V Cd_aN2EzF5NfGuq1z2qEQhpPmIKKSOL2uR4qP9ts- Received: from [99.31.212.42] by web31816.mail.mud.yahoo.com via HTTP; Sat, 14 Apr 2012 09:01:05 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> <3E72A308-75EE-4F5C-96CC-A51F0B81106A@xmlgrrl.com> Message-ID: <1334419265.3552.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Sat, 14 Apr 2012 09:01:05 -0700 (PDT) From: William Mills To: Eve Maler , Hannes Tschofenig In-Reply-To: <3E72A308-75EE-4F5C-96CC-A51F0B81106A@xmlgrrl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-742085045-1334419265=:3552" Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 16:01:16 -0000 ---1238014912-742085045-1334419265=:3552 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, SCIM as a way to federate and distribute info like this seems sane, w= ith extensions for the data items we need here.=A0 The hard part is still a= round the security stuff which they have not dealt with yet, and that's goi= ng to be a blocker until it's solved.=A0 Authority to update elemnts or nam= espaces is going to be needed, and that's a hard problem.=0A=0A-bill=0A=0A= =0A=0A=0A>________________________________=0A> From: Eve Maler =0A>To: Hannes Tschofenig =0A>Cc: "oauth@i= etf.org WG" =0A>Sent: Friday, April 13, 2012 6:29 PM=0A>Su= bject: Re: [OAUTH-WG] Dynamic Client Registration=0A> =0A>Hi Hannes-- That'= s kind of a cool idea. You're right that it's a "client account" of sorts. = At least worth exploring, I'd say, unless a SCIM expert pipes up with a rea= son why not.=0A>=0A>=A0=A0=A0 Eve=0A>=0A>On 13 Apr 2012, at 7:36 AM, Hannes= Tschofenig wrote:=0A>=0A>> Hi all, =0A>> =0A>> at the IETF#83 OAuth workin= g group meeting we had some confusion about the Dynamic Client Registration= and the Simple Web Discovery item. I just listened to the audio recording = again. =0A>> =0A>> With the ongoing mailing list discussion regarding WebFi= nger vs. Simple Web Discovery I hope that folks had a chance to look at the= documents again and so the confusion of some got resolved.=A0 =0A>> =0A>> = I believe the proposed new charter item is sufficiently clear with regard t= o the scope of the work. Right? =0A>> Here is the item again:=0A>> "=0A>> J= ul. 2013=A0 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG= for consideration as a Proposed Standard=0A>> =0A>> [Starting point for th= e work will be =0A>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg= =0A>> ] =0A>> "=0A>> =0A>> Of course there there is a relationship between = Simple Web Discovery (or WebFinger) and the dynamic client registration sin= ce the client first needs to discover the client registration endpoint at t= he authorization server before interacting with it. =0A>> =0A>> Now, one th= ing that just came to my mind when looking again at draft-hardjono-oauth-dy= nreq was the following: Could the Client Registration Request and Response = protocol exchange could become a profile of the SCIM protocol? In some sens= e this exchange is nothing else than provisioning an account at the Authori= zation Server (along with some meta-data).=0A>> =0A>> Is this too far fetch= ed? =0A>> =0A>> Ciao=0A>> Hannes=0A>> =0A>> _______________________________= ________________=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://w= ww.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A>Eve Maler=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.xmlgrrl.com/blog= =0A>+1 425 345 6756=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.twitter.com/xmlgrrl=0A>=0A>____________________________________________= ___=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman= /listinfo/oauth=0A>=0A>=0A> ---1238014912-742085045-1334419265=:3552 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, SCIM as a way to federate and distribute info like this seems sane,= with extensions for the data items we need here.  The hard part is st= ill around the security stuff which they have not dealt with yet, and that'= s going to be a blocker until it's solved.  Authority to update elemnt= s or namespaces is going to be needed, and that's a hard problem.

-bill

<= span style=3D"font-weight:bold;">From: Eve Maler <eve@xmlgrrl.com= >
To: Hannes Tschof= enig <hannes.tschofenig@gmx.net>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Sent: Friday, April 13, 2012 6:2= 9 PM
Subject: Re: [OAU= TH-WG] Dynamic Client Registration

=0AHi Hannes-- Th= at's kind of a cool idea. You're right that it's a "client account" of sort= s. At least worth exploring, I'd say, unless a SCIM expert pipes up with a = reason why not.

    Eve

On 13 Apr 2012, at 7:3= 6 AM, Hannes Tschofenig wrote:

> Hi all,
>
> at the= IETF#83 OAuth working group meeting we had some confusion about the Dynami= c Client Registration and the Simple Web Discovery item. I just listened to= the audio recording again.
>
> With the ongoing mailing list= discussion regarding WebFinger vs. Simple Web Discovery I hope that folks = had a chance to look at the documents again and so the confusion of some go= t resolved. 
>
> I believe the proposed new charter item= is sufficiently clear with regard to the scope of the work. Right?
>= ; Here is the item again:
> "
> Jul. 2013  Submit 'OAuth D= ynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
>
> [Starting point for = the work will be
> http://tools.ietf.org/html/draft-hardjono-oauth-d= ynreg
> ]
> "
>
> Of course there there is a rela= tionship between Simple Web Discovery (or WebFinger) and the dynamic client= registration since the client first needs to discover the client registrat= ion endpoint at the authorization server before interacting with it.
&g= t;
> Now, one thing that just came to my mind when looking again at = draft-hardjono-oauth-dynreq was the following: Could the Client Registratio= n Request and Response protocol exchange could become a profile of the SCIM= protocol? In some sense this exchange is nothing else than provisioning an= account at the Authorization Server (along with some meta-data).
> <= br>> Is this too far fetched?
>
> Ciao
> Hannes
&= gt;
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman= /listinfo/oauth


Eve Maler          =                      = ;   http://www.xmlgrrl.com/blog
+1 425 345 6756     =                   http://www= .twitter.com/xmlgrrl

_______________________________________________=
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth


<= /html> ---1238014912-742085045-1334419265=:3552-- From eran@hueniverse.com Sat Apr 14 23:14:08 2012 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 6D43521F873D for ; Sat, 14 Apr 2012 23:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uxXyoYJcWN5 for ; Sat, 14 Apr 2012 23:14:07 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id CD18A21F8714 for ; Sat, 14 Apr 2012 23:14:07 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id y6E71i0010Dcg9U016E7vj; Sat, 14 Apr 2012 23:14:07 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Sat, 14 Apr 2012 23:14:07 -0700 From: Eran Hammer To: Hannes Tschofenig , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] Dynamic Client Registration Thread-Index: AQHNGYLIAhnVBxyYNEuwmb5Seq6ic5abalPQ Date: Sun, 15 Apr 2012 06:14:06 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F47@P3PWEX2MB008.ex2.secureserver.net> References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> In-Reply-To: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Dynamic Client Registration 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: Sun, 15 Apr 2012 06:14:08 -0000 I'd like to see 'Dynamic Client Registration' removed from the charter alon= g with SWD for the sole reason that figuring out a generic discovery mechan= ism is going to take some time and this WG has enough other work to focus o= n while that happens elsewhere. I expect this to come back in the next roun= d with much more deployment experience and discovery clarity. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Friday, April 13, 2012 7:36 AM > To: oauth@ietf.org WG > Subject: [OAUTH-WG] Dynamic Client Registration >=20 > Hi all, >=20 > at the IETF#83 OAuth working group meeting we had some confusion about > the Dynamic Client Registration and the Simple Web Discovery item. I just > listened to the audio recording again. >=20 > With the ongoing mailing list discussion regarding WebFinger vs. Simple W= eb > Discovery I hope that folks had a chance to look at the documents again a= nd > so the confusion of some got resolved. >=20 > I believe the proposed new charter item is sufficiently clear with regard= to > the scope of the work. Right? > Here is the item again: > " > Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IES= G for > consideration as a Proposed Standard >=20 > [Starting point for the work will be > http://tools.ietf.org/html/draft-hardjono-oauth-dynreg > ] > " >=20 > Of course there there is a relationship between Simple Web Discovery (or > WebFinger) and the dynamic client registration since the client first nee= ds to > discover the client registration endpoint at the authorization server bef= ore > interacting with it. >=20 > Now, one thing that just came to my mind when looking again at draft- > hardjono-oauth-dynreq was the following: Could the Client Registration > Request and Response protocol exchange could become a profile of the > SCIM protocol? In some sense this exchange is nothing else than provision= ing > an account at the Authorization Server (along with some meta-data). >=20 > Is this too far fetched? >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sat Apr 14 23:21:27 2012 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 4AA2C21F86E3 for ; Sat, 14 Apr 2012 23:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HoZKOUQwQ1A for ; Sat, 14 Apr 2012 23:21:25 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id F2CD021F8721 for ; Sat, 14 Apr 2012 23:21:24 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id y6MQ1i0020CJzpC016MQrq; Sat, 14 Apr 2012 23:21:24 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Sat, 14 Apr 2012 23:21:24 -0700 From: Eran Hammer To: Mike Jones , Blaine Cook Thread-Topic: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNGJt5/+q3DOFEzk6CK4fFAhsGypaXuy7ggACDioCAASdpAIACBrSw Date: Sun, 15 Apr 2012 06:21:23 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F63@P3PWEX2MB008.ex2.secureserver.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4E1F6AAD24975D4BA5B168042967394366465919@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436646671B@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436646671B@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F63P3PWEX2MB008ex2se_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Sun, 15 Apr 2012 06:21:27 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F63P3PWEX2MB008ex2se_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG9uZSBhc2lkZSwgdGhpcyBpcyBub3QgdGhlIGZpcnN0IHRpbWUgeW91IGRpc3RvcnRlZCBwcm9j ZXNzIGFuZCB0ZWNobmljYWwgZmFjdHMgdG8gc3VpdCB5b3VyIGdvYWxzLiBKdXN0IGxvb2sgdXAg c29tZSBvZiBvdXIgZXhjaGFuZ2VzIGZyb20gYSB5ZWFyIGFnbyBhbmQgdGhlIHRyYW5zY3JpcHQg b2YgdGhlIFByYWd1ZSBtZWV0aW5nIGZvciBoaWdobGlnaHRzLg0KDQpFSA0KDQoNCg0KRnJvbTog b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBNaWtlIEpvbmVzDQpTZW50OiBGcmlkYXksIEFwcmlsIDEzLCAyMDEyIDk6MTgg QU0NClRvOiBCbGFpbmUgQ29vaw0KQ2M6IG9hdXRoQGlldGYub3JnIFdHDQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBXZWIgRmluZ2VyIHZzLiBTaW1wbGUgV2ViIERpc2NvdmVyeSAoU1dEKQ0KDQpI aSBCbGFpbmUuICBJIG11c3QgYWRtaXQsIEnigJltIHByZXR0eSBzdXJwcmlzZWQgYnkgdGhlIHRv bmUgb2YgeW91ciByZXBseS4gIEnigJlsbCBzYXkgdXAgZnJvbnQgdGhhdCBJIGhhdmUgYWJzb2x1 dGVseSBubyBwcm9ibGVtIHdpdGggYW55b25lIGRpc2FncmVlaW5nIHdpdGggbWUgb24gYSB0ZWNo bmljYWwgb3IgdGFjdGljYWwgYmFzaXMuICBJZiB5b3UgdGhpbmsgSeKAmW0gd3JvbmcsIGhhdmUg YXQgaXQuDQoNCkJ1dCBJIGFtIHByZXR0eSBzaG9ja2VkIHRoYXQgeW91IHdvdWxkIGRlY2lkZSB0 byBpbXB1Z24gbXkgbW90aXZlcy4gIFdl4oCZdmUgb25seSBtZXQgdHdpY2UgYW5kIGJvdGggdGlt ZXMgSSB0aG91Z2h0IHdlIGhhZCByZWFsbHkgdXNlZnVsIGFuZCBwcm9kdWN0aXZlIGRpc2N1c3Np b25zIGFib3V0IGhvdyB0byBtb3ZlIGRpZ2l0YWwgaWRlbnRpdHkgb24gdGhlIFdlYiBmb3J3YXJk IOKAkyBzb21ldGhpbmcgSSBiZWxpZXZlIHRoYXQgd2XigJlyZSBib3RoIHBhc3Npb25hdGUgYWJv dXQuICBZb3UgZG9u4oCZdCByZWFsbHkga25vdyBtZSwgdGhvdWdoLCB3aGljaCBpcyBhcHBhcmVu dCBmcm9tIHlvdXIgcmVtYXJrcyBiZWxvdy4gIEkgYmVsaWV2ZSB0aGF0IHRob3NlIHdobyBoYXZl IHdvcmtlZCB3aXRoIG1lIGZvciB5ZWFycyB3b3VsZCB2b3VjaCB0aGF0IEkgYW0gYSBmb3J0aHJp Z2h0IGFuZCBldmVuaGFuZGVkIHN0YW5kYXJkcyBwYXJ0aWNpcGFudCB3aG8gbGlzdGVucyB0byBh bGwgcG9pbnRzIG9mIHZpZXcsIHRyaWVzIHRvIGJ1aWxkIGEgY29uc2Vuc3VzIHRoYXQgd29ya3Ms IGFuZCBwcm9kdWNlIHF1YWxpdHkgcmVzdWx0cy4NCg0KSSB0aG91Z2h0IGFib3V0IHlvdXIgbm90 ZSBvdmVybmlnaHQgYW5kIHdoZXRoZXIgSSBzaG91bGQgcmVwbHkgYXQgYWxsLiAgSeKAmW0gZmlu ZSB3aXRoIGdpdmUgYW5kIHRha2UsIGJ1dCBJIGJlbGlldmUgdGhhdCBJIG5lZWQgdG8gc2F5IHRo YXQgaWYgeW91IHJlYWQgd2hhdCB5b3Ugd3JvdGUgYmVsb3csIEkgdGhpbmsgeW914oCZbGwgYWdy ZWUgdGhhdCB0aGUgdG9uZSB5b3UgdXNlZCB3YXMgY291bnRlci1wcm9kdWN0aXZlIGFuZCBhbiBh cG9sb2d5IGlzIGluIG9yZGVyLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNClAuUy4gIEnigJlsbCBhZGRyZXNz IHlvdXIgdGVjaG5pY2FsIHBvaW50cyBiZWxvdyBpbiBhIHNlcGFyYXRlIG5vdGUgYXQgc29tZSBw b2ludCDigJMgc29tZSBJIGFncmVlIHdpdGggYW5kIHNvbWUgSSBkb27igJl0LiAgQnV0IEkgZmVs dCB0aGF0IEkgbmVlZGVkIHRvIGFkZHJlc3MgbXkgbW90aXZlcyBiZWluZyBxdWVzdGlvbmVkIHNl cGFyYXRlbHkgYW5kIGZpcnN0LiAgSSBob3BlIHdlIGNhbiBib3RoIGNvbWUgb3V0IG9mIHRoaXMg d2l0aCBhIGJldHRlciB1bmRlcnN0YW5kaW5nIG9mIG9uZSBhbm90aGVyIGFuZCB3b3JrIHRvZ2V0 aGVyIHRvd2FyZHMgdGhlIGltcG9ydGFudCBnb2FscyB0aGF0IHdlIGJvdGggc2hhcmUuDQoNCkZy b206IEJsYWluZSBDb29rIFttYWlsdG86cm9tZWRhQGdtYWlsLmNvbV08bWFpbHRvOlttYWlsdG86 cm9tZWRhQGdtYWlsLmNvbV0+DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTIsIDIwMTIgMzo0MSBQ TQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBIYW5uZXMgVHNjaG9mZW5pZzsgb2F1dGhAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoQGlldGYub3JnPiBXRw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gV2ViIEZp bmdlciB2cy4gU2ltcGxlIFdlYiBEaXNjb3ZlcnkgKFNXRCkNCg0KT24gMTIgQXByaWwgMjAxMiAx Nzo1MSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoYW5rcyBmb3IgYXNraW5nIHRoZXNl IHF1ZXN0aW9ucyBIYW5uZXMuICBJJ2xsIGZpcnN0IHByb3ZpZGUgYSBicmllZiBmZWF0dXJlIGNv bXBhcmlzb24gb2YgU2ltcGxlIFdlYiBEaXNjb3ZlcnkgYW5kIFdlYkZpbmdlciBhbmQgdGhlbiBh bnN3ZXIgeW91ciBxdWVzdGlvbnMuDQoNCkZFQVRVUkUgQ09NUEFSSVNPTg0KDQpSRVNVTFQgR1JB TlVMQVJJVFkgQU5EIFBSSVZBQ1kgQ0hBUkFDVEVSSVNUSUNTOiAgU1dEIHJldHVybnMgdGhlIHJl c291cmNlIGxvY2F0aW9uKHMpIGZvciBhIHNwZWNpZmljIHJlc291cmNlIGZvciBhIHNwZWNpZmlj IHByaW5jaXBhbC4gIFdlYkZpbmdlciByZXR1cm5zIGFsbCByZXNvdXJjZXMgZm9yIHRoZSBwcmlu Y2lwYWwuICBUaGUgZXhhbXBsZSBhdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1q b25lcy1hcHBzYXdnLXdlYmZpbmdlci0wMyNzZWN0aW9uLTMuMiAiUmV0cmlldmluZyBhIFBlcnNv bidzIENvbnRhY3QgSW5mb3JtYXRpb24iIGlzIHRlbGxpbmcuICBUaGUgV2ViRmluZ2VyIHVzYWdl IG1vZGVsIHNlZW1zIHRvIGJlICJJJ2xsIGdldCBldmVyeXRoaW5nIGFib3V0IHlvdSBhbmQgdGhl biBmaXNoIHRocm91Z2ggaXQgdG8gZGVjaWRlIHdoYXQgdG8gZG8gd2l0aCBpdC4iICBUaGUgcHJv dG9jb2wgYXNzdW1wdGlvbiB0aGF0IGFsbCBXZWJGaW5nZXIgaW5mb3JtYXRpb24gbXVzdCBiZSBw dWJsaWMgaXMgYWxzbyBidWlsdCBpbnRvIHRoZSBwcm90b2NvbCB3aGVyZSB0aGUgQ09SUyByZXNw b25zZSBoZWFkZXIgIkFjY2Vzcy1Db250cm9sLUFsbG93LU9yaWdpbjogKiIgaXMgbWFuZGF0ZWQs IHBlciBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1hcHBzYXdnLXdlYmZp bmdlci0wMyNzZWN0aW9uLTcuICBUaGUgcHJpdmFjeSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlc2Ug YXBwcm9hY2hlcyBhcmUgdmVyeSBkaWZmZXJlbnQuICAoSXQncyB0aGVzZSB2ZXJ5IHNhbWUgcHJp dmFjeSBjaGFyYWN0ZXJpc3RpY3MgdGhhdCBsZWQgc3lzYWRtaW5zIHRvIG5lYXJseSB1YmlxdWl0 b3VzbHkgZGlzYWJsaW5nIHRoZSBmaW5nZXJkIHNlcnZpY2UhKSAgUGFydGljdWxhcmx5IGZvciB0 aGUgT0F1dGggdXNlIGNhc2VzLCBuYXJyb3csIHNjb3BlZCwgYW5kIHBvdGVudGlhbGx5IHBlcm1p c3Npb25lZCByZXNwb25zZXMgc2VlbSBwcmVmZXJhYmxlLg0KDQpUaGlzIGlzIGFic29sdXRlbHkg ZmFsc2UuDQoNClNXRCBwcm92aWRlcyBubyBwcml2YWN5IHdoYXRzb2V2ZXIuIFNXRCBtYWtlcyBp dCBzb21ld2hhdCBoYXJkZXIgdG8gY3Jhd2wgbGFyZ2UgbnVtYmVycyBvZiBwcm9maWxlcywgYnV0 IGl0IGRvZXMgbm90IGluY29ycG9yYXRlIGFueSByZWFsIHNlY3VyaXR5LCBhbmQgYW55IGF0dGVt cHQgdG8gc3VnZ2VzdCB0aGF0IGl0IGRvZXMgaXMgbWlzbGVhZGluZyBhbmQgZGVjZXB0aXZlLg0K DQpXZWJmaW5nZXIsIGxpa2UgYW55IGdvb2QgSFRUUCBzZXJ2aWNlLCBpcyBkZXNpZ25lZCB0byBh bGxvdyBhY2Nlc3MgY29udHJvbCB1c2luZyBhcHByb3ByaWF0ZSBtZWFucy4gVGhhdCBhY2Nlc3Mg Y29udHJvbCBzaG91bGQgbm90IGJlICpib3VuZCogdG8gdGhlIHByb3RvY29sLCBpbiB0aGUgc2Ft ZSB3YXkgdGhhdCBIVFRQIGRvZXMgbm90IGhhdmUgYW55IFJFUVVJUkVEIGFjY2VzcyBjb250cm9s IG1lY2hhbmlzbXMsIHNpbmNlIGRvaW5nIHNvIHdvdWxkIHNldmVyZWx5IHJlc3RyaWN0IGZ1dHVy ZSB1c2FnZSBvZiBhIGNvcmUgcHJvdG9jb2wuDQoNCkZVRCBoYXMgbm8gcGxhY2UgaW4gYSBkaXNj dXNzaW9uIG9mIHRoZSB0ZWNobmljYWwgYW5kIHNvY2lhbCBtZXJpdHMgb2YgYSBwcm90b2NvbC4N Cg0KRm9yIHdoYXQgaXQncyB3b3J0aCwgbXkgaW50ZW50IHdpdGggd2ViZmluZ2VyICpmcm9tIGRh eSBvbmUsIG5lYXJseSBmb3VyIHllYXJzIGFnbyosIGhhcyBiZWVuIHRvIHByb3ZpZGUgcGVybWlz c2lvbmVkIHByb2ZpbGUgZGF0YSAqdXNpbmcgRVhJU1RJTkcqIChvciBuZXcsIHdoZXJlIGFwcHJv cHJpYXRlIG9yIG5lY2Vzc2FyeSwgYmFzZWQgb24gKnJ1bm5pbmcgY29kZSBhbmQgZGVwbG95bWVu dCBFWFBFUklFTkNFKikgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtcyBmb3IgcHJvZmlsZSBkYXRh Lg0KDQpUaGUgaWRlYSB0aGF0IHRoZXJlIGlzIE9ORSB2aWV3IG9mIHRoZSBkYXRhIGlzIHBhdGVu dGx5IGZhbHNlLiBGb3IgZXhhbXBsZSwgZGVwZW5kaW5nIG9uIHdobyBpcyByZXF1ZXN0aW5nIG15 IHByb2ZpbGUgZGF0YSwgSSBtaWdodCByZXR1cm4gZGlmZmVyZW50IGNvbnRhY3QgdGVsZXBob25l IG51bWJlcnMsIGFuZCB0aGlzIGJlaGF2aW91ciBpcyBjb21wbGV0ZWx5IGZlYXNpYmxlIHVzaW5n IHdlYmZpbmdlci4NCg0KRE9DVU1FTlQgVkVSU1VTIEFQSSBNT0RFTCwgREVQTE9ZQUJJTElUWSwg QU5EIFNFQ1VSSVRZOiAgV2ViRmluZ2VyIGlzIGJ1aWx0IG9uIGEgImRvY3VtZW50IG1vZGVsIiwg d2hlcmUgYSBzaW5nbGUgZG9jdW1lbnQgaXMgcmV0dXJuZWQgdGhhdCBjb250YWlucyBtdWx0aXBs ZSByZXNvdXJjZXMgZm9yIGEgcHJpbmNpcGFsLiAgU1dEIGlzIGJ1aWx0IG9uIGFuICJBUEkgbW9k ZWwiLCB3aGVyZSB0aGUgbG9jYXRpb24ocykgb2YgYSBwYXJ0aWN1bGFyIHJlc291cmNlIGZvciBh IHByaW5jaXBhbCBhcmUgcmV0dXJuZWQuICBUaGUgcHJvYmxlbSB3aXRoIHRoZSBkb2N1bWVudCBt b2RlbCBpcyB0aGF0IGRpZmZlcmVudCBwYXJ0aWVzIG9yIHNlcnZpY2VzIG1heSBiZSBhdXRob3Jp dGF0aXZlIGZvciBkaWZmZXJlbnQgcmVzb3VyY2VzIGZvciBhIGdpdmVuIHByaW5jaXBhbCwgYW5k IHlldCBhbGwgbmVlZCB0aGUgcmlnaHRzIHRvIGVkaXQgdGhlIHJlc3VsdGluZyBkb2N1bWVudC4g IFRoaXMgaHVydHMgZGVwbG95YWJpbGl0eSwgYmVjYXVzZSBkb2N1bWVudCBlZGl0cyB0aGVuIG5l ZWQgdG8gYmUgY29vcmRpbmF0ZWQgYW1vbmcgcGFydGllcyB0aGF0IG1heSBoYXZlIGRpZmZlcmVu dCByaWdodHMgYW5kIHJlc3BvbnNpYmlsaXRpZXMsIGFuZCBtYXkgaGF2ZSBuZWdhdGl2ZSBzZWN1 cml0eSBpbXBsaWNhdGlvbnMgYXMgd2VsbC4gIChKdXN0IGJlY2F1c2UgSSBjYW4gY2hhbmdlIHlv dXIgYXZhdGFyIGRvZXNuJ3QgbWVhbiB0aGF0IEkgc2hvdWxkIGJlIGFibGUgdG8gY2hhbmdlIHlv dXIgbWFpbCBzZXJ2ZXIuKQ0KDQpXUy0qIHdhcyBidWlsdCBvbiBhbiBBUEkgbW9kZWwsIGFuZCB0 aGF0IHdvcmtlZCBvdXQgdmVyeSB3ZWxsLg0KDQpBUElzIGFuZCBkb2N1bWVudHMgb24gdGhlIHdl YiBhcmUgdGhlIHNhbWUgdGhpbmc7IGhvdyB5b3UgcmVwcmVzZW50IHRoZW0gYmVoaW5kIHRoZSBz Y2VuZXMgaXMgdXAgdG8geW91LCBhbmQgdGhhdCdzIGJlZW4gYSBjb3JlIHByaW5jaXBsZSBvZiB0 aGUgd2ViIHNpbmNlIHNob3J0bHkgYWZ0ZXIgaXRzIGluY2VwdGlvbi4gU3VnZ2VzdGluZyBvdGhl cndpc2UgcHJvZm91bmRseSBtaXN1bmRlcnN0YW5kcyBob3cgaW1wbGVtZW50YXRpb24gb2Ygd2Vi IHNlcnZpY2VzIGhhcHBlbnMuDQoNClNXRCBzYXlzIG5vdGhpbmcgb2YgaG93IHRvIHVwZGF0ZSBw cm9maWxlIGRhdGEsIHNvIHRoZSBzZWN1cml0eSBjb25jZXJucyBoZXJlIGFyZSBhIHRvdGFsIHJl ZCBoZXJyaW5nLg0KDQpSRURJUkVDVCBGVU5DVElPTkFMSVRZIEFORCBERVBMT1lBQklMVFk6ICBT V0QgaW5jbHVkZXMgdGhlIGFiaWxpdHkgdG8gcmVkaXJlY3Qgc29tZSBvciBhbGwgU1dEIHJlcXVl c3RzIHRvIGFub3RoZXIgbG9jYXRpb24gKHBvc3NpYmx5IGRlcGVuZGluZyB1cG9uIHRoZSBzcGVj aWZpYyByZXNvdXJjZSBhbmQgcHJpbmNpcGFsIHBhcmFtZXRlcnMpLiAgRGVwbG95ZXJzIGhvc3Rp bmcgbnVtZXJvdXMgc2l0ZXMgZm9yIG90aGVycyB0b2xkIHRoZSBTV0QgYXV0aG9ycyB0aGF0IHRo aXMgZnVuY3Rpb25hbGl0eSBpcyBjcml0aWNhbCBmb3IgZGVwbG95YWJpbGl0eSwgYXMgaXQgbWVh bnMgdGhhdCB0aGUgU1dEIHNlcnZlciBmb3IgYSBkb21haW4gY2FuIGxpdmUgaW4gYSBsb2NhdGlv biBvdXRzaWRlIHRoZSBkb21haW4uICBXZWJGaW5nZXIgaXMgbGFja2luZyB0aGlzIGZ1bmN0aW9u YWxpdHkuICBHaXZlbiB0aGF0IE9BdXRoIGlzIGxpa2VseSB0byBiZSB1c2VkIGluIGhvc3RlZCBl bnZpcm9ubWVudHMsIHRoaXMgZnVuY3Rpb25hbGl0eSBzZWVtcyBwcmV0dHkgaW1wb3J0YW50Lg0K DQpVbW0sIEknbSBub3QgZXZlbiBzdXJlIHdoYXQgdG8gc2F5IHRvIHRoaXMuIGhvc3QtbWV0YSBp cyBhIHN0YXRpYyBmaWxlIHRoYXQgcG9pbnRzIHRvIGEgcHJvZmlsZSBzZXJ2ZXIgKGdlbmVyYWxs eSBleHBlY3RlZCB0byBiZSBhIGR5bmFtaWMgIkFQSSIgc2VydmVyKSB0aGF0IGNhbiBiZSBob3N0 ZWQgb24gYW55IGRvbWFpbi4NCg0KVGhlIGZhY3QgdGhhdCB5b3UncmUgc3VnZ2VzdGluZyB0aGF0 IHRoaXMgY29yZSBwaWVjZSBvZiB3ZWJmaW5nZXIgZnVuY3Rpb25hbGl0eSBpcyAqbWlzc2luZyog c2VyaW91c2x5IHVuZGVybWluZXMgbXkgYmVsaWVmIHRoYXQgeW91J3JlIGFjdGluZyBpbiBnb29k IGZhaXRoLCBNaWtlLg0KDQpOVU1CRVIgT0YgUk9VTkQgVFJJUFM6ICBXZWJGaW5nZXIgZGlzY292 ZXJpZXMgZm9yIHVzZXIgaW5mb3JtYXRpb24gbm9ybWFsbHkgcmVxdWlyZSBib3RoIGEgaG9zdC1t ZXRhIHF1ZXJ5IHRvIHJldHJpZXZlIHRoZSB0ZW1wbGF0ZSBhbmQgdGhlbiBhIHNlY29uZCBxdWVy eSB0byByZXRyaWV2ZSB0aGUgdXNlcidzIGluZm9ybWF0aW9uLiAgVGhpcyBmdW5jdGlvbmFsaXR5 IGlzIGFjaGlldmVkIGluIGEgc2luZ2xlIFNXRCBxdWVyeS4NCg0KLi4uIGF0IHRoZSBjb3N0IG9m IGdyZWF0ZXIgY2xpZW50IGNvbXBsZXhpdHkuIEEgd2ViZmluZ2VyIGxvb2t1cCBtYXkgYmUgaW1w bGVtZW50ZWQgd2l0aCB0aGUgZm9sbG93aW5nIHRyaXZpYWwgc2hlbGwgc2NyaXB0Og0KDQpjdXJs IC1zIGh0dHA6Ly9leGFtcGxlLmNvbS8ud2VsbC1rbm93bi9ob3N0LW1ldGF8YXdrICIvbHJkZC8s L3RlbXBsYXRlLyJ8dHIgLWQgJ1xuJ3xzZWQgLWUgInMvXi4qdGVtcGxhdGU9J1woW14nXSpcKScu KiQvXDEvInxzZWQgLWUgInMve3VyaX0vdXNlckBleGFtcGxlLmNvbS88aHR0cDovL3VzZXJAZXhh bXBsZS5jb20vPiJ8eGFyZ3MgY3VybCAtcw0KDQpzbyBsb25nIGFzIHlvdXIgSFRUUCBjbGllbnQg cHJvcGVybHkgZm9sbG93cyByZWRpcmVjdHMsIHRoaXMgYXBwcm9hY2ggd2lsbCBhbHdheXMgcHJv ZHVjZSBhIHZhbGlkIHdlYmZpbmdlciBwcm9maWxlLCBhbmQgaWYgcHJvcGVyIGNhY2hpbmcgaXMg aW1wbGVtZW50ZWQsIHdpbGwgb25seSBtYWtlIHJlcXVlc3RzIHRvIC8ud2VsbC1rbm93bi9ob3N0 LW1ldGEgd2hlbiB0aGUgZG9jdW1lbnQgaXMgZXhwaXJlZC4NCg0KU1dELCBvbiB0aGUgb3RoZXIg aGFuZCwgaW1wbGVtZW50cyBhIG5vbi1IVFRQIHJlZGlyZWN0IG1lY2hhbmlzbSwgbWVhbmluZyB0 aGF0IG9wdGltYWwgY2FjaGluZyBydWxlcyBjYW4ndCBiZSBvYmV5ZWQgYnkgc3RhbmRhcmQgSFRU UCBjbGllbnRzLiBNb3Jlb3ZlciwgU1dEICpyZXF1aXJlcyogY29uZGl0aW9uYWxzIGJ5IHByZXNl bnRpbmcgb25lIGNvZGUgcGF0aCBmb3IgdGhlIG5vbi1yZWRpcmVjdCBjYXNlIGFuZCBvbmUgY29k ZSBwYXRoIGZvciB0aGUgaW1tZWRpYXRlIHJlc3BvbnNlIGNhc2UuDQoNClRoZSBjb21wbGV4aXR5 IGZvciBjbGllbnQgaW1wbGVtZW50YXRpb25zIHNob3VsZCBiZSBmb3JlbW9zdCBpbiB0aGlzIHdv cmssIGFuZCB0aGUgZGVjaXNpb25zIG1hZGUgYnkgU1dEIGRvbid0IGluZGljYXRlIHRvIG1lIHRo YXQgdGhlc2UgZmFjdG9ycyBoYXZlIGJlZW4gY29uc2lkZXJlZC4NCg0KSW5kZWVkLCBJIHdvbmRl ciB3aHkgaXMgU1dEIGRlc2lnbmVkIHRvIHByZS1vcHRpbWl6ZSBmb3IgcHJlc3VtZWQgc2NhbGlu ZyBjaGFsbGVuZ2VzIHRoYXQgYXJlIGZhY2VkIGJ5IG9ubHkgdGhlIHZlcnkgbGFyZ2VzdCBwcm92 aWRlcnMgKG5hbWVseSwgdGhlIGZhY3QgdGhhdCB0d28gbG9va3VwcyBhcmUgcmVxdWlyZWQgZm9y IHdlYmZpbmdlciBpbnN0ZWFkIG9mIG9uZSBpbiB0aGUgaWRlYWwgY2FzZSksIHdoZW46DQoNCjEu IFRob3NlIHNjYWxpbmcgY2hhbGxlbmdlcyBhcmUgc2ltcGx5IG5vdCByZWFsIHRocmVhdHMuIGhv c3QtbWV0YSBjYW4gYmUgY2FjaGVkIHVzaW5nIGV4aXN0aW5nIEhUVFAgbWVjaGFuaXNtcw0KMi4g VGhlIGZhY3QgdGhhdCBTV0Qgb25seSByZXR1cm5zIG9uZSBzZXJ2aWNlIGRlZmluaXRpb24gcGVy IHJlcXVlc3QgbWVhbnMgdGhhdCBtb3JlIHRoYW4gb25lIHJlcXVlc3Qgd2lsbCBvZnRlbiBiZSBy ZXF1aXJlZCB0byBvYnRhaW4gdGhlIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiBhYm91dCBhIHVzZXIu DQozLiBUaGUgY2hhbmNlcyB0aGF0IEdvb2dsZSBvciBNaWNyb3NvZnQgd2lsbCBob3N0IGR5bmFt aWMgcmVzcG9uc2UgU1dEIHNlcnZpY2VzIG9uIHRoZSBnbWFpbC5jb208aHR0cDovL2dtYWlsLmNv bT4gb3IgaG90bWFpbC5jb208aHR0cDovL2hvdG1haWwuY29tPiBkb21haW5zIGlzIG5leHQgdG8g bmlsLCBhbmQgd2lsbCB0aGVyZWZvcmUgbmVlZCB0byBpc3N1ZSByZWRpcmVjdHMgYW55d2F5cy4N Cg0KRm9yIHNtYWxsZXIgcHJvdmlkZXJzIChlLmcuLCBwZXJzb25hbCBkb21haW5zIGhvc3RlZCBp biBzdGF0aWMgb3IgcmlnaWQgZW52aXJvbm1lbnRzKSwgaG9zdGluZyBhIFNXRCBzZXJ2ZXIgYXQg Ly53ZWxsLWtub3duL3NpbXBsZS13ZWItZGlzY292ZXJ5IG1heSBiZSBjaGFsbGVuZ2luZyBpbmRl ZWQuIFRodXMsIGFsbCBjbGllbnRzIHdpbGwgbmVlZCB0byBzdXBwb3J0IHRoZSByZWRpcmVjdCBi ZWhhdmlvdXIgbmF0aXZlbHksIGFuZCBmb3IgdGhvc2Ugd2hvIHdyaXRlIHNwZWNzIGJ1dCBub3Qg Y29kZSwgaXQgaXMgKm1vcmUqIGNvbXBsZXggdG8gaGF2ZSBjb25kaXRpb25hbCBiZWhhdmlvdXIg bGlrZSB0aGF0IHRoYW4gdG8gaGF2ZSBhIGRlZmluZWQgZmxvdyB0aGF0IGlzIGFsd2F5cyBmb2xs b3dlZC4NCg0KRnVydGhlciwgaXQncyBtb3JlIGNvbXBsZXggZm9yIHNtYWxsIHNlcnZpY2UgcHJv dmlkZXJzIHRvIGhvc3Qgc3RhdGljIGNvbnRlbnQgdGhhdCBpcyBpbnZhcmlhbnQgYW5kIHByb3Bl cmx5IGNhY2hlZCAoZS5nLiwgYnkgdHJhbnNwYXJlbnQgcHJveHkgY2FjaGVzIGxpa2UgdmFybmlz aCBhbmQgc3F1aWQpIHdoZW4gQ0dJIHBhcmFtZXRlcnMgYXJlIGFwcGVuZGVkLCBhcyB3aXRoIFNX RC4NCg0KWE1MIEFORCBKU09OIFZFUlNVUyBKU09OOiAgV2ViRmluZ2VyIHNwZWNpZmllcyBib3Ro IFhNTCBhbmQgSlNPTiBzdXBwb3J0LCB3aGVyZWFzIFNXRCBzcGVjaWZpZXMgb25seSBKU09OLiAg VGhlIFNXRCBwb3NpdGlvbiBpcyB0aGF0IGl0J3Mgc2ltcGxlciB0byBzcGVjaWZ5IG9ubHkgb25l IHdheSBvZiBkb2luZyB0aGUgc2FtZSB0aGluZywgd2l0aCBKU09OIGJlaW5nIGNob3NlbiBiZWNh dXNlIGl0J3Mgc2ltcGxlciBmb3IgZGV2ZWxvcGVycyB0byB1c2UgdGhhbiBYTUwgLSB0aGUgc2Ft ZSBkZWNpc2lvbiBhcyBtYWRlIGZvciB0aGUgT0F1dGggc3BlY3MuDQoNCldlYmZpbmdlciBvbmx5 IHVzZWQgWFJEIGluIHRoZSBmaXJzdCBwbGFjZSB0byBzYXRpc2Z5IHRoZSBPcGVuSUQgY29tbXVu aXR5LiBUaGlzIGlzIGluZnVyaWF0aW5nIGZvcm1hdC1mZXRpc2hpc20sIGFuZCBtaXNzZXMgdGhl IHBvaW50IGVudGlyZWx5LiBKU09OIGlzIHByZWZlcnJlZCwgYW5kIEksIGZvciBvbmUsIHdvdWxk IGhhcHBpbHkgbW9kaWZ5IGhvc3QtbWV0YSBhbmQgd2ViZmluZ2VyIHRvIHJlcXVpcmUgSlNPTiBp cyBwZW9wbGUgZmVlbCB0aGlzIHN0cm9uZ2x5IGFib3V0IGl0Lg0KDQpERUZJTklORyBTUEVDSUZJ QyBSRVNPVVJDRVM6ICBCZXNpZGVzIHNwZWNpZnlpbmcgYSBkaXNjb3ZlcnkgcHJvdG9jb2wsIFdl YkZpbmdlciBhbHNvIGRlZmluZXMgc3BlY2lmaWMgcmVzb3VyY2VzIGFuZCBraW5kcyBvZiByZXNv dXJjZXMgdG8gYmUgdXNlZCB3aXRoIHRoYXQgcHJvdG9jb2w6ICB0aGUgImFjY3QiIFVSSSBzY2hl bWUsIHRoZSAiYWNjdCIgTGluayBSZWxhdGlvbi4gIFRoZXNlIHNob3VsZCBiZSBjb25zaWRlcmVk IG9uIHRoZWlyIG93biBtZXJpdHMsIGJ1dCBsb2dpY2FsbHkgc2hvdWxkIGJlIGRlY291cGxlZCBm cm9tIHRoZSBkaXNjb3ZlcnkgcHJvdG9jb2wgaW50byBhIGRpZmZlcmVudCBkb2N1bWVudCBvciBk b2N1bWVudHMuICBJdCdzIG5vdCBjbGVhciB0aGVzZSBmZWF0dXJlcyB3b3VsZCBiZSBuZWVkZWQg aW4gT0F1dGggY29udGV4dHMuDQoNCkkgaGF2ZSBsb25nIGFyZ3VlZCBhZ2FpbnN0IHRoZSBhY2N0 IFVSSSwgYnV0IHRoZSBjb25zZW5zdXMtYmFzZWQgYXBwcm9hY2ggb2YgdGhlIElFVEYgaGFzIG92 ZXItcmlkZGVuIG1lIG9uIHRoYXQgb25lLiBJZiB5b3UgZmVlbCBzaW1pbGFybHksIHlvdSBhcmUg ZnJlZSB0byB2b2ljZSB0aGF0IG9waW5pb24uDQoNCkl0IHNob2NrcyBtZSB0aGF0IHlvdSdyZSBz YXlpbmcgdGhhdCB0aGUgT0F1dGggV0cgc2hvdWxkbid0IGNvbnNpZGVyIGhvc3QtbWV0YS93ZWJm aW5nZXIgYmVjYXVzZSBpdCBkZWZpbmVzIHNvbWV0aGluZyB0aGF0IGlzbid0IG9mIGludGVyZXN0 IHRvIHRoZSBPQXV0aCBXRy4gVGhlIHdob2xlIHBvaW50IG9mIG15IGFyZ3VtZW50IGF0IHRoZSBX RyBtZWV0aW5nIGluIFBhcmlzIHdhcyB0aGF0IFdlYmZpbmdlciBhbmQgU1dELWxpa2UgcHJvdG9j b2xzIGFyZSBvZiBzdWNoIGNvbnNlcXVlbmNlIHRvIHRoZSB3ZWIgYXQgbGFyZ2UgdGhhdCB0aGUg aW50ZXJlc3RzIG9mIHRoZSBPQXV0aCBXRyBzaG91bGQgbm90IGJlIHVzZWQgdG8gZGVmaW5lIHRo ZSBwYXJhbWV0ZXJzIGZvciB0aGVpciBiZWhhdmlvdXIuDQoNCkknbSBtb3JlIGNvbnZpbmNlZCB0 aGF0IHlvdSdyZSB1c2luZyB5b3VyIHBvd2VyIHdpdGhpbiB0aGlzIFdHIHRvIGhhdmUgU1dEIHJ1 YmJlci1zdGFtcGVkIHNvIHRoYXQgeW91IGNhbiBzaGlwIE9wZW5JRCBDb25uZWN0IGFzIHlvdSd2 ZSBkZWZpbmVkIGl0Lg0KDQpRVUVTVElPTlMNCg0KMSkgQXJlbid0IHRoZXNlIHR3byBtZWNoYW5p c21zIHNvbHZpbmcgcHJldHR5IG11Y2ggdGhlIHNhbWUgcHJvYmxlbT8NCiAgICAgICAgICAgICAg VGhleSBhcmUgc29sdmluZyBhbiBvdmVybGFwcGluZyBzZXQgb2YgcHJvYmxlbXMsIGJ1dCB3aXRo IHZlcnkgZGlmZmVyZW50IHByaXZhY3kgY2hhcmFjdGVyaXN0aWNzLCBkaWZmZXJlbnQgZGVwbG95 YWJpbGl0eSBjaGFyYWN0ZXJpc3RpY3MsIGRpZmZlcmVudCBzZWN1cml0eSBjaGFyYWN0ZXJpc3Rp Y3MsIGFuZCBzb21ld2hhdCBkaWZmZXJlbnQgbWVjaGFuaXNtcy4NCg0KQWdhaW4sIEkgdG90YWxs eSBkaXNhZ3JlZSB3aXRoIHlvdXIgYXNzZXNzbWVudCBoZXJlLCBNaWtlLg0KDQoyKSBEbyB3ZSBu ZWVkIHRvIGhhdmUgdHdvIHN0YW5kYXJkcyBmb3IgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eT8NCiAg ICAgICAgICAgICAgTm8gLSBTaW1wbGUgV2ViIERpc2NvdmVyeSBpcyBzdWZmaWNpZW50IGZvciB0 aGUgT0F1dGggdXNlIGNhc2VzIChhbmQgbGlrZWx5IGZvciBvdGhlcnMgYXMgd2VsbCkuDQoNCkkg YWdyZWUgd2l0aCB0aGlzIOKAkyBzaW5jZSBTV0QgaXMgYW4gZXhwbGljaXQgKHRob3VnaCB1bnN0 YXRlZCkgZm9yayBvZiBXZWJmaW5nZXIsIHRoZXJlIGlzIG5vIG5lZWQgdG8gaGF2ZSB0d28gc3Rh bmRhcmRzLg0KDQozKSBEbyB5b3UgZ3V5cyBoYXZlIGEgcG9zaXRpb24gb3IgY29tbWVudHMgcmVn YXJkaW5nIGVpdGhlciBvbmUgb2YgdGhlbT8NCiAgICAgICAgICAgICAgVGhlIGZ1bmN0aW9uYWxp dHkgaW4gU2ltcGxlIFdlYiBEaXNjb3ZlcnkgaXMgbWluaW1hbCBhbmQgc3VmZmljaWVudCBmb3Ig dGhlIE9BdXRoIHVzZSBjYXNlcywgd2hlcmVhcyBzb21lIG9mIHRoZSBmdW5jdGlvbmFsaXR5IGFu ZCBhc3N1bXB0aW9ucyBtYWRlIGluIFdlYkZpbmdlciBhcmUgaGFybWZ1bCwgYm90aCBmcm9tIGEg cHJpdmFjeSBhbmQgZnJvbSBhIGRlcGxveWFiaWxpdHkgcGVyc3BlY3RpdmUuICBTV0Qgc2hvdWxk IHByb2NlZWQgdG8gc3RhbmRhcmRpemF0aW9uOyBXZWJGaW5nZXIgc2hvdWxkIG5vdC4NCg0KSSBi ZWxpZXZlIE1pa2UgaGFzIG1hZGUgbWlzbGVhZGluZyBzdGF0ZW1lbnRzIHJlZ2FyZGluZyB0aGUg cHJpdmFjeSBhbmQgZGVwbG95YWJpbGl0eSBwZXJzcGVjdGl2ZSwgZWl0aGVyIGludGVudGlvbmFs bHksIG9yIGJlY2F1c2UgaGUgZnVuZGFtZW50YWxseSBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSBz ZWN1cml0eSBvciBkZXBsb3ltZW50IHNjZW5hcmlvcyB0aGF0IG1vdGl2YXRlIHRoZSBkZWNpc2lv bnMuDQoNCkluIHN1bW1hcnk6DQoNCjEuIEkgYmVsaWV2ZSB0aGF0IFNXRCBhbmQgV2ViZmluZ2Vy IGFyZSBlc3NlbnRpYWxseSB0aGUgc2FtZSBwcm90b2NvbCwgd2l0aCBkaWZmZXJlbnQgYXV0aG9y cyBuYW1lcyBhdCB0aGUgdG9wLg0KMi4gSSBkb24ndCBjYXJlIHdoaWNoIG9uZSAid2lucyIsIHRo b3VnaCBJIHRoaW5rIHRoYXQgU1dEJ3MgdXNlIG9mIEhUVFAgaXMgcXVlc3Rpb25hYmxlLCBhbmQg dGhhdCB0aGUgY2xhaW1zIG9mIHByaXZhY3kgYW5kIGRlcGxveWFiaWxpdHkgYWR2YW50YWdlcyBv ZmZlcmVkIGJ5IFNXRCBhcmUgb3ZlcmJsb3duIGFuZCBwb3RlbnRpYWxseSBtaXNsZWFkaW5nLg0K My4gTXkgY29uY2VybnMgYWJvdXQgU1dEIGFwcGx5IGVxdWFsbHkgdG8gYW55IGNvbmNlcm5zIGFu eW9uZSB3b3VsZCBsZXZlcmFnZSBhZ2FpbnN0IFdlYmZpbmdlci4NCjQuIFdoaWNoIGlzIHRvIHNh eSwgSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBvbmUgcHJvdG9jb2wgdGhhdCBpcyBkZWZpbmVkIGJ5 IGFuIG9wZW4gZGlzY3Vzc2lvbi4NCjUuIFdlJ3ZlIGhhZCBhbiBvcGVuIGRpc2N1c3Npb24gb24g dGhlIHdlYmZpbmdlciBsaXN0IGFuZCBhcHBzLWRpc2N1c3MgYW5kIGluIHRoZSBjb250ZXh0IG9m IGhvc3QtbWV0YSB0aGF0IHRoZSBTV0QgZm9sa3MgaGF2ZSBjaG9zZW4gbm90IHRvIGVuZ2FnZSB3 aXRoIGZvciB0aGUgcGFzdCB0aHJlZSB5ZWFycy4NCjYuIFRoZSBPQXV0aCBsaXN0IGlzICpub3Qq IHRoZSBwbGFjZSBmb3IgdGhpcyBkaXNjdXNzaW9uIHRvIGhhcHBlbiwganVzdCBzbyB0aGF0IE1p a2UgSm9uZXMgY2FuIHF1aWNrbHkgcHVzaCBhIHNwZWMgdGhyb3VnaCB0aGUgZm9ybWFsIHByb2Nl c3MgdXNpbmcgYSBsaXN0IHRoYXQgaGFzIHdlbGwta25vd24gcHJvYmxlbXMgb2YgdG9vLWhpZ2gg bWFpbCB2b2x1bWUgYW5kIHdob3NlIHRvcGljIGlzIHVucmVsYXRlZCB0byB0aGUgZ29hbHMgb2Yg V2ViZmluZ2VyL1NXRC4NCg0KVGhpcyBpcyBpbXBvcnRhbnQgZW5vdWdoIHRvIGdldCByaWdodCwg YW5kIGdldHRpbmcgaXQgd3Jvbmcgd2lsbCBhbG1vc3QgY2VydGFpbmx5IGxlYWQgdG8geWVhcnMg b2YgaW5jb21wYXRpYmlsaXR5IGFuZCBmcnVzdHJhdGlvbiwgYXMgU3RlcGhlbiBtZW50aW9uZWQu IEkgZW5jb3VyYWdlIGV2ZXJ5b25lIGludm9sdmVkIHRvIHRha2UgdGhpcyBzZXJpb3VzbHksIGxl dCBnbyBvZiBwZXJzb25hbCBhdHRhY2htZW50IGFuZCBwcmVzdW1wdGlvbnMgb2YgZGVwZW5kZW5j aWVzLCBhbmQgY29uc2lkZXIgdGhpcyB3b3JrIGluIGFuIGFwcHJvcHJpYXRlIGNvbnRleHQgKHdp dGggYW4gaW5jbHVzaXZlLCBub3QgZXhjbHVzaXZlIGNvbW11bml0eSkuDQoNCmIuDQo= --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F63P3PWEX2MB008ex2se_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRvbmUg YXNpZGUsIHRoaXMgaXMgbm90IHRoZSBmaXJzdCB0aW1lIHlvdSBkaXN0b3J0ZWQgcHJvY2VzcyBh bmQgdGVjaG5pY2FsIGZhY3RzIHRvIHN1aXQgeW91ciBnb2Fscy4gSnVzdCBsb29rIHVwIHNvbWUg b2Ygb3VyIGV4Y2hhbmdlcyBmcm9tIGEgeWVhciBhZ28gYW5kDQogdGhlIHRyYW5zY3JpcHQgb2Yg dGhlIFByYWd1ZSBtZWV0aW5nIGZvciBoaWdobGlnaHRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RUg8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBvYXV0 aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmls IDEzLCAyMDEyIDk6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IEJsYWluZSBDb29rPGJyPg0KPGI+Q2M6 PC9iPiBvYXV0aEBpZXRmLm9yZyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdH XSBXZWIgRmluZ2VyIHZzLiBTaW1wbGUgV2ViIERpc2NvdmVyeSAoU1dEKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSBCbGFpbmUuJm5ic3A7IEkgbXVzdCBhZG1pdCwgSeKAmW0g cHJldHR5IHN1cnByaXNlZCBieSB0aGUgdG9uZSBvZiB5b3VyIHJlcGx5LiZuYnNwOyBJ4oCZbGwg c2F5IHVwIGZyb250IHRoYXQgSSBoYXZlIGFic29sdXRlbHkgbm8gcHJvYmxlbSB3aXRoIGFueW9u ZSBkaXNhZ3JlZWluZyB3aXRoDQogbWUgb24gYSB0ZWNobmljYWwgb3IgdGFjdGljYWwgYmFzaXMu Jm5ic3A7IElmIHlvdSB0aGluayBJ4oCZbSB3cm9uZywgaGF2ZSBhdCBpdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1 dCBJIGFtIHByZXR0eSBzaG9ja2VkIHRoYXQgeW91IHdvdWxkIGRlY2lkZSB0byBpbXB1Z24gbXkg bW90aXZlcy4mbmJzcDsgV2XigJl2ZSBvbmx5IG1ldCB0d2ljZSBhbmQgYm90aCB0aW1lcyBJIHRo b3VnaHQgd2UgaGFkIHJlYWxseSB1c2VmdWwgYW5kIHByb2R1Y3RpdmUgZGlzY3Vzc2lvbnMNCiBh Ym91dCBob3cgdG8gbW92ZSBkaWdpdGFsIGlkZW50aXR5IG9uIHRoZSBXZWIgZm9yd2FyZCDigJMg c29tZXRoaW5nIEkgYmVsaWV2ZSB0aGF0IHdl4oCZcmUgYm90aCBwYXNzaW9uYXRlIGFib3V0LiZu YnNwOyBZb3UgZG9u4oCZdCByZWFsbHkga25vdyBtZSwgdGhvdWdoLCB3aGljaCBpcyBhcHBhcmVu dCBmcm9tIHlvdXIgcmVtYXJrcyBiZWxvdy4mbmJzcDsgSSBiZWxpZXZlIHRoYXQgdGhvc2Ugd2hv IGhhdmUgd29ya2VkIHdpdGggbWUgZm9yIHllYXJzIHdvdWxkIHZvdWNoDQogdGhhdCBJIGFtIGEg Zm9ydGhyaWdodCBhbmQgZXZlbmhhbmRlZCBzdGFuZGFyZHMgcGFydGljaXBhbnQgd2hvIGxpc3Rl bnMgdG8gYWxsIHBvaW50cyBvZiB2aWV3LCB0cmllcyB0byBidWlsZCBhIGNvbnNlbnN1cyB0aGF0 IHdvcmtzLCBhbmQgcHJvZHVjZSBxdWFsaXR5IHJlc3VsdHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRob3VnaHQg YWJvdXQgeW91ciBub3RlIG92ZXJuaWdodCBhbmQgd2hldGhlciBJIHNob3VsZCByZXBseSBhdCBh bGwuJm5ic3A7IEnigJltIGZpbmUgd2l0aCBnaXZlIGFuZCB0YWtlLCBidXQgSSBiZWxpZXZlIHRo YXQgSSBuZWVkIHRvIHNheSB0aGF0IGlmIHlvdSByZWFkIHdoYXQNCiB5b3Ugd3JvdGUgYmVsb3cs IEkgdGhpbmsgeW914oCZbGwgYWdyZWUgdGhhdCB0aGUgdG9uZSB5b3UgdXNlZCB3YXMgY291bnRl ci1wcm9kdWN0aXZlIGFuZCBhbiBhcG9sb2d5IGlzIGluIG9yZGVyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlAuUy4mbmJzcDsgSeKAmWxsIGFkZHJlc3MgeW91ciB0 ZWNobmljYWwgcG9pbnRzIGJlbG93IGluIGEgc2VwYXJhdGUgbm90ZSBhdCBzb21lIHBvaW50IOKA kyBzb21lIEkgYWdyZWUgd2l0aCBhbmQgc29tZSBJIGRvbuKAmXQuJm5ic3A7IEJ1dCBJIGZlbHQg dGhhdCBJIG5lZWRlZCB0byBhZGRyZXNzIG15DQogbW90aXZlcyBiZWluZyBxdWVzdGlvbmVkIHNl cGFyYXRlbHkgYW5kIGZpcnN0LiZuYnNwOyBJIGhvcGUgd2UgY2FuIGJvdGggY29tZSBvdXQgb2Yg dGhpcyB3aXRoIGEgYmV0dGVyIHVuZGVyc3RhbmRpbmcgb2Ygb25lIGFub3RoZXIgYW5kIHdvcmsg dG9nZXRoZXIgdG93YXJkcyB0aGUgaW1wb3J0YW50IGdvYWxzIHRoYXQgd2UgYm90aCBzaGFyZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJsYWluZSBDb29rDQo8 YSBocmVmPSJtYWlsdG86W21haWx0bzpyb21lZGFAZ21haWwuY29tXSI+W21haWx0bzpyb21lZGFA Z21haWwuY29tXTwvYT4gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAxMiwgMjAx MiAzOjQxIFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBIYW5u ZXMgVHNjaG9mZW5pZzsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRm Lm9yZzwvYT4gV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gV2ViIEZpbmdl ciB2cy4gU2ltcGxlIFdlYiBEaXNjb3ZlcnkgKFNXRCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIDEyIEFwcmlsIDIwMTIgMTc6NTEsIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzIGZvciBhc2tpbmcgdGhlc2UgcXVlc3Rpb25zIEhhbm5lcy4gJm5ic3A7SSdsbCBmaXJz dCBwcm92aWRlIGEgYnJpZWYgZmVhdHVyZSBjb21wYXJpc29uIG9mIFNpbXBsZSBXZWIgRGlzY292 ZXJ5IGFuZCBXZWJGaW5nZXIgYW5kIHRoZW4gYW5zd2VyIHlvdXIgcXVlc3Rpb25zLjxicj4NCjxi cj4NCkZFQVRVUkUgQ09NUEFSSVNPTjxicj4NCjxicj4NClJFU1VMVCBHUkFOVUxBUklUWSBBTkQg UFJJVkFDWSBDSEFSQUNURVJJU1RJQ1M6ICZuYnNwO1NXRCByZXR1cm5zIHRoZSByZXNvdXJjZSBs b2NhdGlvbihzKSBmb3IgYSBzcGVjaWZpYyByZXNvdXJjZSBmb3IgYSBzcGVjaWZpYyBwcmluY2lw YWwuICZuYnNwO1dlYkZpbmdlciByZXR1cm5zIGFsbCByZXNvdXJjZXMgZm9yIHRoZSBwcmluY2lw YWwuICZuYnNwO1RoZSBleGFtcGxlIGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1qb25lcy1hcHBzYXdnLXdlYmZpbmdlci0wMyNzZWN0aW9uLTMuMiIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtYXBwc2F3 Zy13ZWJmaW5nZXItMDMjc2VjdGlvbi0zLjI8L2E+ICZxdW90O1JldHJpZXZpbmcgYSBQZXJzb24n cyBDb250YWN0IEluZm9ybWF0aW9uJnF1b3Q7IGlzIHRlbGxpbmcuICZuYnNwO1RoZSBXZWJGaW5n ZXIgdXNhZ2UgbW9kZWwgc2VlbXMgdG8gYmUgJnF1b3Q7SSdsbCBnZXQgZXZlcnl0aGluZyBhYm91 dCB5b3UgYW5kIHRoZW4gZmlzaCB0aHJvdWdoIGl0IHRvIGRlY2lkZSB3aGF0IHRvIGRvIHdpdGgg aXQuJnF1b3Q7DQogJm5ic3A7VGhlIHByb3RvY29sIGFzc3VtcHRpb24gdGhhdCBhbGwgV2ViRmlu Z2VyIGluZm9ybWF0aW9uIG11c3QgYmUgcHVibGljIGlzIGFsc28gYnVpbHQgaW50byB0aGUgcHJv dG9jb2wgd2hlcmUgdGhlIENPUlMgcmVzcG9uc2UgaGVhZGVyICZxdW90O0FjY2Vzcy1Db250cm9s LUFsbG93LU9yaWdpbjogKiZxdW90OyBpcyBtYW5kYXRlZCwgcGVyDQo8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1hcHBzYXdnLXdlYmZpbmdlci0wMyNzZWN0 aW9uLTciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWpvbmVzLWFwcHNhd2ctd2ViZmluZ2VyLTAzI3NlY3Rpb24tNzwvYT4uICZuYnNwO1RoZSBwcml2 YWN5IGNoYXJhY3RlcmlzdGljcyBvZiB0aGVzZSBhcHByb2FjaGVzIGFyZSB2ZXJ5IGRpZmZlcmVu dC4gJm5ic3A7KEl0J3MgdGhlc2UgdmVyeSBzYW1lIHByaXZhY3kgY2hhcmFjdGVyaXN0aWNzIHRo YXQgbGVkIHN5c2FkbWlucyB0byBuZWFybHkgdWJpcXVpdG91c2x5IGRpc2FibGluZyB0aGUgZmlu Z2VyZCBzZXJ2aWNlISkNCiAmbmJzcDtQYXJ0aWN1bGFybHkgZm9yIHRoZSBPQXV0aCB1c2UgY2Fz ZXMsIG5hcnJvdywgc2NvcGVkLCBhbmQgcG90ZW50aWFsbHkgcGVybWlzc2lvbmVkIHJlc3BvbnNl cyBzZWVtIHByZWZlcmFibGUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGFic29sdXRlbHkgZmFsc2UuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNXRCBwcm92aWRl cyBubyBwcml2YWN5IHdoYXRzb2V2ZXIuIFNXRCBtYWtlcyBpdCBzb21ld2hhdCBoYXJkZXIgdG8g Y3Jhd2wgbGFyZ2UgbnVtYmVycyBvZiBwcm9maWxlcywgYnV0IGl0IGRvZXMgbm90IGluY29ycG9y YXRlIGFueSByZWFsIHNlY3VyaXR5LCBhbmQgYW55IGF0dGVtcHQgdG8gc3VnZ2VzdCB0aGF0IGl0 IGRvZXMgaXMgbWlzbGVhZGluZyBhbmQgZGVjZXB0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZWJmaW5nZXIsIGxpa2UgYW55IGdvb2Qg SFRUUCBzZXJ2aWNlLCBpcyBkZXNpZ25lZCB0byBhbGxvdyBhY2Nlc3MgY29udHJvbCB1c2luZyBh cHByb3ByaWF0ZSBtZWFucy4gVGhhdCBhY2Nlc3MgY29udHJvbCBzaG91bGQgbm90IGJlICpib3Vu ZCogdG8gdGhlIHByb3RvY29sLCBpbiB0aGUgc2FtZSB3YXkgdGhhdCBIVFRQIGRvZXMgbm90IGhh dmUgYW55IFJFUVVJUkVEIGFjY2VzcyBjb250cm9sIG1lY2hhbmlzbXMsDQogc2luY2UgZG9pbmcg c28gd291bGQgc2V2ZXJlbHkgcmVzdHJpY3QgZnV0dXJlIHVzYWdlIG9mIGEgY29yZSBwcm90b2Nv bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RlVEIGhhcyBubyBwbGFjZSBpbiBhIGRpc2N1c3Npb24gb2YgdGhlIHRlY2huaWNhbCBhbmQgc29j aWFsIG1lcml0cyBvZiBhIHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3Igd2hhdCBpdCdzIHdvcnRoLCBteSBpbnRlbnQgd2l0 aCB3ZWJmaW5nZXIgKmZyb20gZGF5IG9uZSwgbmVhcmx5IGZvdXIgeWVhcnMgYWdvKiwgaGFzIGJl ZW4gdG8gcHJvdmlkZSBwZXJtaXNzaW9uZWQgcHJvZmlsZSBkYXRhICp1c2luZyBFWElTVElORyog KG9yIG5ldywgd2hlcmUgYXBwcm9wcmlhdGUgb3IgbmVjZXNzYXJ5LCBiYXNlZCBvbiAqcnVubmlu ZyBjb2RlIGFuZCBkZXBsb3ltZW50IEVYUEVSSUVOQ0UqKQ0KIGFjY2VzcyBjb250cm9sIG1lY2hh bmlzbXMgZm9yIHByb2ZpbGUgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlkZWEgdGhhdCB0aGVyZSBpcyBPTkUgdmlldyBvZiB0 aGUgZGF0YSBpcyBwYXRlbnRseSBmYWxzZS4gRm9yIGV4YW1wbGUsIGRlcGVuZGluZyBvbiB3aG8g aXMgcmVxdWVzdGluZyBteSBwcm9maWxlIGRhdGEsIEkgbWlnaHQgcmV0dXJuIGRpZmZlcmVudCBj b250YWN0IHRlbGVwaG9uZSBudW1iZXJzLCBhbmQgdGhpcyBiZWhhdmlvdXIgaXMgY29tcGxldGVs eSBmZWFzaWJsZSB1c2luZyB3ZWJmaW5nZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5ET0NVTUVOVCBWRVJTVVMgQVBJIE1PREVMLCBERVBMT1lBQklMSVRZLCBBTkQg U0VDVVJJVFk6ICZuYnNwO1dlYkZpbmdlciBpcyBidWlsdCBvbiBhICZxdW90O2RvY3VtZW50IG1v ZGVsJnF1b3Q7LCB3aGVyZSBhIHNpbmdsZSBkb2N1bWVudCBpcyByZXR1cm5lZCB0aGF0IGNvbnRh aW5zIG11bHRpcGxlIHJlc291cmNlcyBmb3IgYSBwcmluY2lwYWwuICZuYnNwO1NXRCBpcyBidWls dCBvbiBhbiAmcXVvdDtBUEkgbW9kZWwmcXVvdDssIHdoZXJlIHRoZSBsb2NhdGlvbihzKQ0KIG9m IGEgcGFydGljdWxhciByZXNvdXJjZSBmb3IgYSBwcmluY2lwYWwgYXJlIHJldHVybmVkLiAmbmJz cDtUaGUgcHJvYmxlbSB3aXRoIHRoZSBkb2N1bWVudCBtb2RlbCBpcyB0aGF0IGRpZmZlcmVudCBw YXJ0aWVzIG9yIHNlcnZpY2VzIG1heSBiZSBhdXRob3JpdGF0aXZlIGZvciBkaWZmZXJlbnQgcmVz b3VyY2VzIGZvciBhIGdpdmVuIHByaW5jaXBhbCwgYW5kIHlldCBhbGwgbmVlZCB0aGUgcmlnaHRz IHRvIGVkaXQgdGhlIHJlc3VsdGluZyBkb2N1bWVudC4NCiAmbmJzcDtUaGlzIGh1cnRzIGRlcGxv eWFiaWxpdHksIGJlY2F1c2UgZG9jdW1lbnQgZWRpdHMgdGhlbiBuZWVkIHRvIGJlIGNvb3JkaW5h dGVkIGFtb25nIHBhcnRpZXMgdGhhdCBtYXkgaGF2ZSBkaWZmZXJlbnQgcmlnaHRzIGFuZCByZXNw b25zaWJpbGl0aWVzLCBhbmQgbWF5IGhhdmUgbmVnYXRpdmUgc2VjdXJpdHkgaW1wbGljYXRpb25z IGFzIHdlbGwuICZuYnNwOyhKdXN0IGJlY2F1c2UgSSBjYW4gY2hhbmdlIHlvdXIgYXZhdGFyIGRv ZXNuJ3QgbWVhbiB0aGF0DQogSSBzaG91bGQgYmUgYWJsZSB0byBjaGFuZ2UgeW91ciBtYWlsIHNl cnZlci4pPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XUy0qIHdhcyBidWlsdCBvbiBhbiBBUEkgbW9kZWwsIGFuZCB0aGF0IHdvcmtl ZCBvdXQgdmVyeSB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BUElzIGFuZCBkb2N1bWVudHMgb24gdGhlIHdlYiBhcmUgdGhlIHNhbWUg dGhpbmc7IGhvdyB5b3UgcmVwcmVzZW50IHRoZW0gYmVoaW5kIHRoZSBzY2VuZXMgaXMgdXAgdG8g eW91LCBhbmQgdGhhdCdzIGJlZW4gYSBjb3JlIHByaW5jaXBsZSBvZiB0aGUgd2ViIHNpbmNlIHNo b3J0bHkgYWZ0ZXIgaXRzIGluY2VwdGlvbi4gU3VnZ2VzdGluZyBvdGhlcndpc2UgcHJvZm91bmRs eSBtaXN1bmRlcnN0YW5kcyBob3cgaW1wbGVtZW50YXRpb24NCiBvZiB3ZWIgc2VydmljZXMgaGFw cGVucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U1dEIHNheXMgbm90aGluZyBvZiBob3cgdG8gdXBkYXRlIHByb2ZpbGUgZGF0YSwgc28gdGhl IHNlY3VyaXR5IGNvbmNlcm5zIGhlcmUgYXJlIGEgdG90YWwgcmVkIGhlcnJpbmcuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SRURJUkVDVCBGVU5DVElPTkFMSVRZIEFO RCBERVBMT1lBQklMVFk6ICZuYnNwO1NXRCBpbmNsdWRlcyB0aGUgYWJpbGl0eSB0byByZWRpcmVj dCBzb21lIG9yIGFsbCBTV0QgcmVxdWVzdHMgdG8gYW5vdGhlciBsb2NhdGlvbiAocG9zc2libHkg ZGVwZW5kaW5nIHVwb24gdGhlIHNwZWNpZmljIHJlc291cmNlIGFuZCBwcmluY2lwYWwgcGFyYW1l dGVycykuICZuYnNwO0RlcGxveWVycyBob3N0aW5nIG51bWVyb3VzIHNpdGVzIGZvcg0KIG90aGVy cyB0b2xkIHRoZSBTV0QgYXV0aG9ycyB0aGF0IHRoaXMgZnVuY3Rpb25hbGl0eSBpcyBjcml0aWNh bCBmb3IgZGVwbG95YWJpbGl0eSwgYXMgaXQgbWVhbnMgdGhhdCB0aGUgU1dEIHNlcnZlciBmb3Ig YSBkb21haW4gY2FuIGxpdmUgaW4gYSBsb2NhdGlvbiBvdXRzaWRlIHRoZSBkb21haW4uICZuYnNw O1dlYkZpbmdlciBpcyBsYWNraW5nIHRoaXMgZnVuY3Rpb25hbGl0eS4gJm5ic3A7R2l2ZW4gdGhh dCBPQXV0aCBpcyBsaWtlbHkgdG8gYmUgdXNlZCBpbiBob3N0ZWQNCiBlbnZpcm9ubWVudHMsIHRo aXMgZnVuY3Rpb25hbGl0eSBzZWVtcyBwcmV0dHkgaW1wb3J0YW50LjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW1tLCBJJ20gbm90 IGV2ZW4gc3VyZSB3aGF0IHRvIHNheSB0byB0aGlzLiBob3N0LW1ldGEgaXMgYSBzdGF0aWMgZmls ZSB0aGF0IHBvaW50cyB0byBhIHByb2ZpbGUgc2VydmVyIChnZW5lcmFsbHkgZXhwZWN0ZWQgdG8g YmUgYSBkeW5hbWljICZxdW90O0FQSSZxdW90OyBzZXJ2ZXIpIHRoYXQgY2FuIGJlIGhvc3RlZCBv biBhbnkgZG9tYWluLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgZmFjdCB0aGF0IHlvdSdyZSBzdWdnZXN0aW5nIHRoYXQgdGhpcyBjb3Jl IHBpZWNlIG9mIHdlYmZpbmdlciBmdW5jdGlvbmFsaXR5IGlzICptaXNzaW5nKiBzZXJpb3VzbHkg dW5kZXJtaW5lcyBteSBiZWxpZWYgdGhhdCB5b3UncmUgYWN0aW5nIGluIGdvb2QgZmFpdGgsIE1p a2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OVU1CRVIgT0YgUk9V TkQgVFJJUFM6ICZuYnNwO1dlYkZpbmdlciBkaXNjb3ZlcmllcyBmb3IgdXNlciBpbmZvcm1hdGlv biBub3JtYWxseSByZXF1aXJlIGJvdGggYSBob3N0LW1ldGEgcXVlcnkgdG8gcmV0cmlldmUgdGhl IHRlbXBsYXRlIGFuZCB0aGVuIGEgc2Vjb25kIHF1ZXJ5IHRvIHJldHJpZXZlIHRoZSB1c2VyJ3Mg aW5mb3JtYXRpb24uICZuYnNwO1RoaXMgZnVuY3Rpb25hbGl0eSBpcyBhY2hpZXZlZCBpbiBhIHNp bmdsZQ0KIFNXRCBxdWVyeS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi4uLiBhdCB0aGUgY29zdCBvZiBncmVhdGVyIGNsaWVudCBj b21wbGV4aXR5LiBBIHdlYmZpbmdlciBsb29rdXAgbWF5IGJlIGltcGxlbWVudGVkIHdpdGggdGhl IGZvbGxvd2luZyB0cml2aWFsIHNoZWxsIHNjcmlwdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5jdXJsIC1zIDxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNv bS8ud2VsbC1rbm93bi9ob3N0LW1ldGF8YXdrIj4NCmh0dHA6Ly9leGFtcGxlLmNvbS8ud2VsbC1r bm93bi9ob3N0LW1ldGF8YXdrPC9hPiAmcXVvdDsvbHJkZC8sL3RlbXBsYXRlLyZxdW90O3x0ciAt ZCAnXG4nfHNlZCAtZSAmcXVvdDtzL14uKnRlbXBsYXRlPSdcKFteJ10qXCknLiokL1wxLyZxdW90 O3xzZWQgLWUgJnF1b3Q7cy97dXJpfS88YSBocmVmPSJodHRwOi8vdXNlckBleGFtcGxlLmNvbS8i PnVzZXJAZXhhbXBsZS5jb20vPC9hPiZxdW90O3x4YXJncyBjdXJsIC1zPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zbyBsb25nIGFz IHlvdXIgSFRUUCBjbGllbnQgcHJvcGVybHkgZm9sbG93cyByZWRpcmVjdHMsIHRoaXMgYXBwcm9h Y2ggd2lsbCBhbHdheXMgcHJvZHVjZSBhIHZhbGlkIHdlYmZpbmdlciBwcm9maWxlLCBhbmQgaWYg cHJvcGVyIGNhY2hpbmcgaXMgaW1wbGVtZW50ZWQsIHdpbGwgb25seSBtYWtlIHJlcXVlc3RzIHRv IC8ud2VsbC1rbm93bi9ob3N0LW1ldGEgd2hlbiB0aGUgZG9jdW1lbnQgaXMgZXhwaXJlZC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U1dELCBv biB0aGUgb3RoZXIgaGFuZCwgaW1wbGVtZW50cyBhIG5vbi1IVFRQIHJlZGlyZWN0IG1lY2hhbmlz bSwgbWVhbmluZyB0aGF0IG9wdGltYWwgY2FjaGluZyBydWxlcyBjYW4ndCBiZSBvYmV5ZWQgYnkg c3RhbmRhcmQgSFRUUCBjbGllbnRzLiBNb3Jlb3ZlciwgU1dEICpyZXF1aXJlcyogY29uZGl0aW9u YWxzIGJ5IHByZXNlbnRpbmcgb25lIGNvZGUgcGF0aCBmb3IgdGhlIG5vbi1yZWRpcmVjdCBjYXNl IGFuZA0KIG9uZSBjb2RlIHBhdGggZm9yIHRoZSBpbW1lZGlhdGUgcmVzcG9uc2UgY2FzZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNv bXBsZXhpdHkgZm9yIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIGJlIGZvcmVtb3N0IGlu IHRoaXMgd29yaywgYW5kIHRoZSBkZWNpc2lvbnMgbWFkZSBieSBTV0QgZG9uJ3QgaW5kaWNhdGUg dG8gbWUgdGhhdCB0aGVzZSBmYWN0b3JzIGhhdmUgYmVlbiBjb25zaWRlcmVkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmRlZWQsIEkgd29u ZGVyIHdoeSZuYnNwO2lzIFNXRCBkZXNpZ25lZCB0byBwcmUtb3B0aW1pemUgZm9yIHByZXN1bWVk IHNjYWxpbmcgY2hhbGxlbmdlcyB0aGF0IGFyZSBmYWNlZCBieSBvbmx5IHRoZSB2ZXJ5IGxhcmdl c3QgcHJvdmlkZXJzIChuYW1lbHksIHRoZSBmYWN0IHRoYXQgdHdvIGxvb2t1cHMgYXJlIHJlcXVp cmVkIGZvciB3ZWJmaW5nZXIgaW5zdGVhZCBvZiBvbmUgaW4gdGhlIGlkZWFsIGNhc2UpLCB3aGVu OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4x LiBUaG9zZSBzY2FsaW5nIGNoYWxsZW5nZXMgYXJlIHNpbXBseSBub3QgcmVhbCB0aHJlYXRzLiBo b3N0LW1ldGEgY2FuIGJlIGNhY2hlZCB1c2luZyBleGlzdGluZyBIVFRQIG1lY2hhbmlzbXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFRoZSBm YWN0IHRoYXQgU1dEIG9ubHkgcmV0dXJucyBvbmUgc2VydmljZSBkZWZpbml0aW9uIHBlciByZXF1 ZXN0IG1lYW5zIHRoYXQgbW9yZSB0aGFuIG9uZSByZXF1ZXN0IHdpbGwgb2Z0ZW4gYmUgcmVxdWly ZWQgdG8gb2J0YWluIHRoZSBuZWNlc3NhcnkgaW5mb3JtYXRpb24gYWJvdXQgYSB1c2VyLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gVGhlIGNo YW5jZXMgdGhhdCBHb29nbGUgb3IgTWljcm9zb2Z0IHdpbGwgaG9zdCBkeW5hbWljIHJlc3BvbnNl IFNXRCBzZXJ2aWNlcyBvbiB0aGUNCjxhIGhyZWY9Imh0dHA6Ly9nbWFpbC5jb20iPmdtYWlsLmNv bTwvYT4gb3IgPGEgaHJlZj0iaHR0cDovL2hvdG1haWwuY29tIj5ob3RtYWlsLmNvbTwvYT4gZG9t YWlucyBpcyBuZXh0IHRvIG5pbCwgYW5kIHdpbGwgdGhlcmVmb3JlIG5lZWQgdG8gaXNzdWUgcmVk aXJlY3RzIGFueXdheXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkZvciBzbWFsbGVyIHByb3ZpZGVycyAoZS5nLiwgcGVyc29uYWwgZG9tYWlu cyBob3N0ZWQgaW4gc3RhdGljIG9yIHJpZ2lkIGVudmlyb25tZW50cyksIGhvc3RpbmcgYSBTV0Qg c2VydmVyIGF0IC8ud2VsbC1rbm93bi9zaW1wbGUtd2ViLWRpc2NvdmVyeSBtYXkgYmUgY2hhbGxl bmdpbmcgaW5kZWVkLiBUaHVzLCBhbGwgY2xpZW50cyB3aWxsIG5lZWQgdG8gc3VwcG9ydCB0aGUg cmVkaXJlY3QgYmVoYXZpb3VyIG5hdGl2ZWx5LA0KIGFuZCBmb3IgdGhvc2Ugd2hvIHdyaXRlIHNw ZWNzIGJ1dCBub3QgY29kZSwgaXQgaXMgKm1vcmUqIGNvbXBsZXggdG8gaGF2ZSBjb25kaXRpb25h bCBiZWhhdmlvdXIgbGlrZSB0aGF0IHRoYW4gdG8gaGF2ZSBhIGRlZmluZWQgZmxvdyB0aGF0IGlz IGFsd2F5cyBmb2xsb3dlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RnVydGhlciwgaXQncyBtb3JlIGNvbXBsZXggZm9yIHNtYWxsIHNlcnZp Y2UgcHJvdmlkZXJzIHRvIGhvc3Qgc3RhdGljIGNvbnRlbnQgdGhhdCBpcyBpbnZhcmlhbnQgYW5k IHByb3Blcmx5IGNhY2hlZCAoZS5nLiwgYnkgdHJhbnNwYXJlbnQgcHJveHkgY2FjaGVzIGxpa2Ug dmFybmlzaCBhbmQgc3F1aWQpIHdoZW4gQ0dJIHBhcmFtZXRlcnMgYXJlIGFwcGVuZGVkLCBhcyB3 aXRoIFNXRC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlhNTCBBTkQg SlNPTiBWRVJTVVMgSlNPTjogJm5ic3A7V2ViRmluZ2VyIHNwZWNpZmllcyBib3RoIFhNTCBhbmQg SlNPTiBzdXBwb3J0LCB3aGVyZWFzIFNXRCBzcGVjaWZpZXMgb25seSBKU09OLiAmbmJzcDtUaGUg U1dEIHBvc2l0aW9uIGlzIHRoYXQgaXQncyBzaW1wbGVyIHRvIHNwZWNpZnkgb25seSBvbmUgd2F5 IG9mIGRvaW5nIHRoZSBzYW1lIHRoaW5nLCB3aXRoIEpTT04gYmVpbmcgY2hvc2VuIGJlY2F1c2Ug aXQncyBzaW1wbGVyDQogZm9yIGRldmVsb3BlcnMgdG8gdXNlIHRoYW4gWE1MIC0gdGhlIHNhbWUg ZGVjaXNpb24gYXMgbWFkZSBmb3IgdGhlIE9BdXRoIHNwZWNzLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2ViZmluZ2VyIG9ubHkg dXNlZCBYUkQgaW4gdGhlIGZpcnN0IHBsYWNlIHRvIHNhdGlzZnkgdGhlIE9wZW5JRCBjb21tdW5p dHkuIFRoaXMgaXMgaW5mdXJpYXRpbmcgZm9ybWF0LWZldGlzaGlzbSwgYW5kIG1pc3NlcyB0aGUg cG9pbnQgZW50aXJlbHkuIEpTT04gaXMgcHJlZmVycmVkLCBhbmQgSSwgZm9yIG9uZSwgd291bGQg aGFwcGlseSBtb2RpZnkgaG9zdC1tZXRhIGFuZCB3ZWJmaW5nZXIgdG8gcmVxdWlyZQ0KIEpTT04g aXMgcGVvcGxlIGZlZWwgdGhpcyBzdHJvbmdseSBhYm91dCBpdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRFRklOSU5HIFNQRUNJRklDIFJFU09VUkNFUzogJm5ic3A7 QmVzaWRlcyBzcGVjaWZ5aW5nIGEgZGlzY292ZXJ5IHByb3RvY29sLCBXZWJGaW5nZXIgYWxzbyBk ZWZpbmVzIHNwZWNpZmljIHJlc291cmNlcyBhbmQga2luZHMgb2YgcmVzb3VyY2VzIHRvIGJlIHVz ZWQgd2l0aCB0aGF0IHByb3RvY29sOiAmbmJzcDt0aGUgJnF1b3Q7YWNjdCZxdW90OyBVUkkgc2No ZW1lLCB0aGUgJnF1b3Q7YWNjdCZxdW90OyBMaW5rIFJlbGF0aW9uLiAmbmJzcDtUaGVzZSBzaG91 bGQgYmUgY29uc2lkZXJlZA0KIG9uIHRoZWlyIG93biBtZXJpdHMsIGJ1dCBsb2dpY2FsbHkgc2hv dWxkIGJlIGRlY291cGxlZCBmcm9tIHRoZSBkaXNjb3ZlcnkgcHJvdG9jb2wgaW50byBhIGRpZmZl cmVudCBkb2N1bWVudCBvciBkb2N1bWVudHMuICZuYnNwO0l0J3Mgbm90IGNsZWFyIHRoZXNlIGZl YXR1cmVzIHdvdWxkIGJlIG5lZWRlZCBpbiBPQXV0aCBjb250ZXh0cy48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBsb25n IGFyZ3VlZCBhZ2FpbnN0IHRoZSBhY2N0IFVSSSwgYnV0IHRoZSBjb25zZW5zdXMtYmFzZWQgYXBw cm9hY2ggb2YgdGhlIElFVEYgaGFzIG92ZXItcmlkZGVuIG1lIG9uIHRoYXQgb25lLiBJZiB5b3Ug ZmVlbCBzaW1pbGFybHksIHlvdSBhcmUgZnJlZSB0byB2b2ljZSB0aGF0IG9waW5pb24uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNob2Nr cyBtZSB0aGF0IHlvdSdyZSBzYXlpbmcgdGhhdCB0aGUgT0F1dGggV0cgc2hvdWxkbid0IGNvbnNp ZGVyIGhvc3QtbWV0YS93ZWJmaW5nZXIgYmVjYXVzZSBpdCBkZWZpbmVzIHNvbWV0aGluZyB0aGF0 IGlzbid0IG9mIGludGVyZXN0IHRvIHRoZSBPQXV0aCBXRy4gVGhlIHdob2xlIHBvaW50IG9mIG15 IGFyZ3VtZW50IGF0IHRoZSBXRyBtZWV0aW5nIGluIFBhcmlzIHdhcyB0aGF0IFdlYmZpbmdlciBh bmQNCiBTV0QtbGlrZSBwcm90b2NvbHMgYXJlIG9mIHN1Y2ggY29uc2VxdWVuY2UgdG8gdGhlIHdl YiBhdCBsYXJnZSB0aGF0IHRoZSBpbnRlcmVzdHMgb2YgdGhlIE9BdXRoIFdHIHNob3VsZCBub3Qg YmUgdXNlZCB0byBkZWZpbmUgdGhlIHBhcmFtZXRlcnMgZm9yIHRoZWlyIGJlaGF2aW91ci48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG1v cmUgY29udmluY2VkIHRoYXQgeW91J3JlIHVzaW5nIHlvdXIgcG93ZXIgd2l0aGluIHRoaXMgV0cg dG8gaGF2ZSBTV0QgcnViYmVyLXN0YW1wZWQgc28gdGhhdCB5b3UgY2FuIHNoaXAgT3BlbklEIENv bm5lY3QgYXMgeW91J3ZlIGRlZmluZWQgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5RVUVTVElPTlM8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjEpIEFyZW4ndCB0aGVz ZSB0d28gbWVjaGFuaXNtcyBzb2x2aW5nIHByZXR0eSBtdWNoIHRoZSBzYW1lIHByb2JsZW0/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGV5IGFyZSBzb2x2aW5nIGFuIG92 ZXJsYXBwaW5nIHNldCBvZiBwcm9ibGVtcywgYnV0IHdpdGggdmVyeSBkaWZmZXJlbnQgcHJpdmFj eSBjaGFyYWN0ZXJpc3RpY3MsIGRpZmZlcmVudCBkZXBsb3lhYmlsaXR5IGNoYXJhY3RlcmlzdGlj cywgZGlmZmVyZW50IHNlY3VyaXR5IGNoYXJhY3RlcmlzdGljcywgYW5kIHNvbWV3aGF0IGRpZmZl cmVudCBtZWNoYW5pc21zLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdhaW4sIEkgdG90YWxseSBkaXNhZ3JlZSB3aXRoIHlvdXIg YXNzZXNzbWVudCBoZXJlLCBNaWtlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+MikgRG8gd2UgbmVlZCB0 byBoYXZlIHR3byBzdGFuZGFyZHMgZm9yIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHk/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBObyAtIFNpbXBsZSBXZWIgRGlzY292ZXJ5IGlz IHN1ZmZpY2llbnQgZm9yIHRoZSBPQXV0aCB1c2UgY2FzZXMgKGFuZCBsaWtlbHkgZm9yIG90aGVy cyBhcyB3ZWxsKS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0aCB0aGlzIOKAkyBzaW5jZSBTV0QgaXMgYW4gZXhw bGljaXQgKHRob3VnaCB1bnN0YXRlZCkgZm9yayBvZiBXZWJmaW5nZXIsIHRoZXJlIGlzIG5vIG5l ZWQgdG8gaGF2ZSB0d28gc3RhbmRhcmRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+MykgRG8geW91IGd1 eXMgaGF2ZSBhIHBvc2l0aW9uIG9yIGNvbW1lbnRzIHJlZ2FyZGluZyBlaXRoZXIgb25lIG9mIHRo ZW0/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgZnVuY3Rpb25hbGl0 eSBpbiBTaW1wbGUgV2ViIERpc2NvdmVyeSBpcyBtaW5pbWFsIGFuZCBzdWZmaWNpZW50IGZvciB0 aGUgT0F1dGggdXNlIGNhc2VzLCB3aGVyZWFzIHNvbWUgb2YgdGhlIGZ1bmN0aW9uYWxpdHkgYW5k IGFzc3VtcHRpb25zIG1hZGUgaW4gV2ViRmluZ2VyIGFyZSBoYXJtZnVsLCBib3RoIGZyb20gYSBw cml2YWN5IGFuZCBmcm9tIGEgZGVwbG95YWJpbGl0eSBwZXJzcGVjdGl2ZS4NCiAmbmJzcDtTV0Qg c2hvdWxkIHByb2NlZWQgdG8gc3RhbmRhcmRpemF0aW9uOyBXZWJGaW5nZXIgc2hvdWxkIG5vdC48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgYmVsaWV2ZSBNaWtlIGhhcyBtYWRlIG1pc2xlYWRpbmcgc3RhdGVtZW50cyByZWdhcmRp bmcgdGhlIHByaXZhY3kgYW5kIGRlcGxveWFiaWxpdHkgcGVyc3BlY3RpdmUsIGVpdGhlciBpbnRl bnRpb25hbGx5LCBvciBiZWNhdXNlIGhlIGZ1bmRhbWVudGFsbHkgZG9lcyBub3QgdW5kZXJzdGFu ZCB0aGUgc2VjdXJpdHkgb3IgZGVwbG95bWVudCBzY2VuYXJpb3MgdGhhdCBtb3RpdmF0ZSB0aGUg ZGVjaXNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JbiBzdW1tYXJ5OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4xLiBJIGJlbGlldmUgdGhhdCBTV0QgYW5kIFdlYmZpbmdlciBhcmUg ZXNzZW50aWFsbHkgdGhlIHNhbWUgcHJvdG9jb2wsIHdpdGggZGlmZmVyZW50IGF1dGhvcnMgbmFt ZXMgYXQgdGhlIHRvcC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjIuIEkgZG9uJ3QgY2FyZSB3aGljaCBvbmUgJnF1b3Q7d2lucyZxdW90OywgdGhv dWdoIEkgdGhpbmsgdGhhdCBTV0QncyB1c2Ugb2YgSFRUUCBpcyBxdWVzdGlvbmFibGUsIGFuZCB0 aGF0IHRoZSBjbGFpbXMgb2YgcHJpdmFjeSBhbmQgZGVwbG95YWJpbGl0eSBhZHZhbnRhZ2VzIG9m ZmVyZWQgYnkgU1dEIGFyZSBvdmVyYmxvd24gYW5kIHBvdGVudGlhbGx5IG1pc2xlYWRpbmcuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBNeSBj b25jZXJucyBhYm91dCBTV0QgYXBwbHkgZXF1YWxseSB0byBhbnkgY29uY2VybnMgYW55b25lIHdv dWxkIGxldmVyYWdlIGFnYWluc3QgV2ViZmluZ2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4gV2hpY2ggaXMgdG8gc2F5LCBJIHRoaW5rIHdl IHNob3VsZCBoYXZlIG9uZSBwcm90b2NvbCB0aGF0IGlzIGRlZmluZWQgYnkgYW4gb3BlbiBkaXNj dXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+NS4gV2UndmUgaGFkIGFuIG9wZW4gZGlzY3Vzc2lvbiBvbiB0aGUgd2ViZmluZ2VyIGxpc3Qg YW5kIGFwcHMtZGlzY3VzcyBhbmQgaW4gdGhlIGNvbnRleHQgb2YgaG9zdC1tZXRhIHRoYXQgdGhl IFNXRCBmb2xrcyBoYXZlIGNob3NlbiBub3QgdG8gZW5nYWdlIHdpdGggZm9yIHRoZSBwYXN0IHRo cmVlIHllYXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Ni4gVGhlIE9BdXRoIGxpc3QgaXMgKm5vdCogdGhlIHBsYWNlIGZvciB0aGlzIGRpc2N1 c3Npb24gdG8gaGFwcGVuLCBqdXN0IHNvIHRoYXQgTWlrZSBKb25lcyBjYW4gcXVpY2tseSBwdXNo IGEgc3BlYyB0aHJvdWdoIHRoZSBmb3JtYWwgcHJvY2VzcyB1c2luZyBhIGxpc3QgdGhhdCBoYXMg d2VsbC1rbm93biBwcm9ibGVtcyBvZiB0b28taGlnaCBtYWlsIHZvbHVtZSBhbmQgd2hvc2UgdG9w aWMgaXMgdW5yZWxhdGVkDQogdG8gdGhlIGdvYWxzIG9mIFdlYmZpbmdlci9TV0QuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgaW1w b3J0YW50IGVub3VnaCB0byBnZXQgcmlnaHQsIGFuZCBnZXR0aW5nIGl0IHdyb25nIHdpbGwgYWxt b3N0IGNlcnRhaW5seSBsZWFkIHRvIHllYXJzIG9mIGluY29tcGF0aWJpbGl0eSBhbmQgZnJ1c3Ry YXRpb24sIGFzIFN0ZXBoZW4gbWVudGlvbmVkLiBJIGVuY291cmFnZSBldmVyeW9uZSBpbnZvbHZl ZCB0byB0YWtlIHRoaXMgc2VyaW91c2x5LCBsZXQgZ28gb2YgcGVyc29uYWwgYXR0YWNobWVudA0K IGFuZCBwcmVzdW1wdGlvbnMgb2YgZGVwZW5kZW5jaWVzLCBhbmQgY29uc2lkZXIgdGhpcyB3b3Jr IGluIGFuIGFwcHJvcHJpYXRlIGNvbnRleHQgKHdpdGggYW4gaW5jbHVzaXZlLCBub3QgZXhjbHVz aXZlIGNvbW11bml0eSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F63P3PWEX2MB008ex2se_-- From melvincarvalho@gmail.com Sun Apr 15 01:56:17 2012 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 0F29821F86AD for ; Sun, 15 Apr 2012 01:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyx9piLJr9mL for ; Sun, 15 Apr 2012 01:56:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C19421F86F3 for ; Sun, 15 Apr 2012 01:56:06 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3338522vbb.31 for ; Sun, 15 Apr 2012 01:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=arPAoL+6QkaG9ck5J7zUfxRImlcEH2KqESJ2Zp/bJLc=; b=IWaQuSQ53dzqeFBMSIC2dFYl1AuXQz4NtXIKCX9ufDIz/Lz5Kn+lFNSZsq3NlZp10C 5n3vnPWcAL+Q098nYOYWdqSY814rXpPnVgXm4ksaob+hK9Gkrafrv/GoVR1+lcZFio9u s3/fPJ7hvylNcRKGC1m1Xyket//oiby6n5+ZIPr+z4G4GHNqWcWPvhrKA1uYcYvIVI6G U5mlDK915KflAW12C1R2H6AxGeLldgMo4kjUz1HPR/S8QW4cz6PIzTfFRCQAaxgZW/ZY hBxAS0vT5EtR6hY9xT0dTigJDGzZFuGsFX3Lje7GIfGWGOqb7/e66lYJyFedHbVdT+BV zFlw== MIME-Version: 1.0 Received: by 10.52.90.178 with SMTP id bx18mr3102216vdb.123.1334480165439; Sun, 15 Apr 2012 01:56:05 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Sun, 15 Apr 2012 01:56:05 -0700 (PDT) In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F63@P3PWEX2MB008.ex2.secureserver.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4E1F6AAD24975D4BA5B168042967394366465919@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436646671B@TK5EX14MBXC283.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F63@P3PWEX2MB008.ex2.secureserver.net> Date: Sun, 15 Apr 2012 10:56:05 +0200 Message-ID: From: Melvin Carvalho To: Eran Hammer Content-Type: multipart/alternative; boundary=20cf3071cffa38891e04bdb3e04b Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Sun, 15 Apr 2012 08:56:17 -0000 --20cf3071cffa38891e04bdb3e04b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 15 April 2012 08:21, Eran Hammer wrote: > Tone aside, this is not the first time you distorted process and > technical facts to suit your goals. Just look up some of our exchanges fr= om > a year ago and the transcript of the Prague meeting for highlights. > As stephen suggests, could we possibly continue this fascinating discussion on apps discuss? I know people are passionate about this issue, and that's a positive thing. But I think it probably would be most productive, if we could all try to keep personal attacks to a minimum. > **** > > ** ** > > EH**** > > ** ** > > ** ** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Mike Jones > *Sent:* Friday, April 13, 2012 9:18 AM > *To:* Blaine Cook > *Cc:* oauth@ietf.org WG > > *Subject:* Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)**** > > ** ** > > Hi Blaine. I must admit, I=92m pretty surprised by the tone of your repl= y. > I=92ll say up front that I have absolutely no problem with anyone disagre= eing > with me on a technical or tactical basis. If you think I=92m wrong, have= at > it.**** > > ** ** > > But I am pretty shocked that you would decide to impugn my motives. We= =92ve > only met twice and both times I thought we had really useful and producti= ve > discussions about how to move digital identity on the Web forward =96 > something I believe that we=92re both passionate about. You don=92t real= ly > know me, though, which is apparent from your remarks below. I believe th= at > those who have worked with me for years would vouch that I am a forthrigh= t > and evenhanded standards participant who listens to all points of view, > tries to build a consensus that works, and produce quality results.**** > > ** ** > > I thought about your note overnight and whether I should reply at all. > I=92m fine with give and take, but I believe that I need to say that if y= ou > read what you wrote below, I think you=92ll agree that the tone you used = was > counter-productive and an apology is in order.**** > > ** ** > > -- Mike**** > > ** ** > > P.S. I=92ll address your technical points below in a separate note at so= me > point =96 some I agree with and some I don=92t. But I felt that I needed= to > address my motives being questioned separately and first. I hope we can > both come out of this with a better understanding of one another and work > together towards the important goals that we both share.**** > > ** ** > > *From:* Blaine Cook [mailto:romeda@gmail.com] > *Sent:* Thursday, April 12, 2012 3:41 PM > *To:* Mike Jones > *Cc:* Hannes Tschofenig; oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)**** > > ** ** > > On 12 April 2012 17:51, Mike Jones wrote:**= * > * > > Thanks for asking these questions Hannes. I'll first provide a brief > feature comparison of Simple Web Discovery and WebFinger and then answer > your questions. > > FEATURE COMPARISON > > RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: SWD returns the resource > location(s) for a specific resource for a specific principal. WebFinger > returns all resources for the principal. The example at > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2"R= etrieving a Person's Contact Information" is telling. The WebFinger > usage model seems to be "I'll get everything about you and then fish > through it to decide what to do with it." The protocol assumption that a= ll > WebFinger information must be public is also built into the protocol wher= e > the CORS response header "Access-Control-Allow-Origin: *" is mandated, pe= r > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7. > The privacy characteristics of these approaches are very different. (It= 's > these very same privacy characteristics that led sysadmins to nearly > ubiquitously disabling the fingerd service!) Particularly for the OAuth > use cases, narrow, scoped, and potentially permissioned responses seem > preferable.**** > > ** ** > > This is absolutely false.**** > > ** ** > > SWD provides no privacy whatsoever. SWD makes it somewhat harder to crawl > large numbers of profiles, but it does not incorporate any real security, > and any attempt to suggest that it does is misleading and deceptive.**** > > ** ** > > Webfinger, like any good HTTP service, is designed to allow access contro= l > using appropriate means. That access control should not be *bound* to the > protocol, in the same way that HTTP does not have any REQUIRED access > control mechanisms, since doing so would severely restrict future usage o= f > a core protocol.**** > > ** ** > > FUD has no place in a discussion of the technical and social merits of a > protocol.**** > > ** ** > > For what it's worth, my intent with webfinger *from day one, nearly four > years ago*, has been to provide permissioned profile data *using EXISTING= * > (or new, where appropriate or necessary, based on *running code and > deployment EXPERIENCE*) access control mechanisms for profile data.**** > > ** ** > > The idea that there is ONE view of the data is patently false. For > example, depending on who is requesting my profile data, I might return > different contact telephone numbers, and this behaviour is completely > feasible using webfinger.**** > > **** > > DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURITY: WebFinger is > built on a "document model", where a single document is returned that > contains multiple resources for a principal. SWD is built on an "API > model", where the location(s) of a particular resource for a principal ar= e > returned. The problem with the document model is that different parties = or > services may be authoritative for different resources for a given > principal, and yet all need the rights to edit the resulting document. > This hurts deployability, because document edits then need to be > coordinated among parties that may have different rights and > responsibilities, and may have negative security implications as well. > (Just because I can change your avatar doesn't mean that I should be abl= e > to change your mail server.)**** > > ** ** > > WS-* was built on an API model, and that worked out very well.**** > > ** ** > > APIs and documents on the web are the same thing; how you represent them > behind the scenes is up to you, and that's been a core principle of the w= eb > since shortly after its inception. Suggesting otherwise profoundly > misunderstands how implementation of web services happens.**** > > ** ** > > SWD says nothing of how to update profile data, so the security concerns > here are a total red herring.**** > > **** > > REDIRECT FUNCTIONALITY AND DEPLOYABILTY: SWD includes the ability to > redirect some or all SWD requests to another location (possibly depending > upon the specific resource and principal parameters). Deployers hosting > numerous sites for others told the SWD authors that this functionality is > critical for deployability, as it means that the SWD server for a domain > can live in a location outside the domain. WebFinger is lacking this > functionality. Given that OAuth is likely to be used in hosted > environments, this functionality seems pretty important.**** > > ** ** > > Umm, I'm not even sure what to say to this. host-meta is a static file > that points to a profile server (generally expected to be a dynamic "API" > server) that can be hosted on any domain.**** > > ** ** > > The fact that you're suggesting that this core piece of webfinger > functionality is *missing* seriously undermines my belief that you're > acting in good faith, Mike.**** > > **** > > NUMBER OF ROUND TRIPS: WebFinger discoveries for user information > normally require both a host-meta query to retrieve the template and then= a > second query to retrieve the user's information. This functionality is > achieved in a single SWD query.**** > > ** ** > > ... at the cost of greater client complexity. A webfinger lookup may be > implemented with the following trivial shell script:**** > > ** ** > > curl -s http://example.com/.well-known/host-meta|awk"/lrdd/,/template/"|t= r -d '\n'|sed -e > "s/^.*template=3D'\([^']*\)'.*$/\1/"|sed -e "s/{uri}/user@example.com/"|x= args > curl -s**** > > **** > > so long as your HTTP client properly follows redirects, this approach wil= l > always produce a valid webfinger profile, and if proper caching is > implemented, will only make requests to /.well-known/host-meta when the > document is expired.**** > > ** ** > > SWD, on the other hand, implements a non-HTTP redirect mechanism, meaning > that optimal caching rules can't be obeyed by standard HTTP clients. > Moreover, SWD *requires* conditionals by presenting one code path for the > non-redirect case and one code path for the immediate response case.**** > > ** ** > > The complexity for client implementations should be foremost in this work= , > and the decisions made by SWD don't indicate to me that these factors hav= e > been considered.**** > > ** ** > > Indeed, I wonder why is SWD designed to pre-optimize for presumed scaling > challenges that are faced by only the very largest providers (namely, the > fact that two lookups are required for webfinger instead of one in the > ideal case), when:**** > > ** ** > > 1. Those scaling challenges are simply not real threats. host-meta can be > cached using existing HTTP mechanisms**** > > 2. The fact that SWD only returns one service definition per request mean= s > that more than one request will often be required to obtain the necessary > information about a user.**** > > 3. The chances that Google or Microsoft will host dynamic response SWD > services on the gmail.com or hotmail.com domains is next to nil, and will > therefore need to issue redirects anyways.**** > > ** ** > > For smaller providers (e.g., personal domains hosted in static or rigid > environments), hosting a SWD server at /.well-known/simple-web-discovery > may be challenging indeed. Thus, all clients will need to support the > redirect behaviour natively, and for those who write specs but not code, = it > is *more* complex to have conditional behaviour like that than to have a > defined flow that is always followed.**** > > ** ** > > Further, it's more complex for small service providers to host static > content that is invariant and properly cached (e.g., by transparent proxy > caches like varnish and squid) when CGI parameters are appended, as with > SWD.**** > > ** ** > > XML AND JSON VERSUS JSON: WebFinger specifies both XML and JSON support, > whereas SWD specifies only JSON. The SWD position is that it's simpler t= o > specify only one way of doing the same thing, with JSON being chosen > because it's simpler for developers to use than XML - the same decision a= s > made for the OAuth specs.**** > > ** ** > > Webfinger only used XRD in the first place to satisfy the OpenID > community. This is infuriating format-fetishism, and misses the point > entirely. JSON is preferred, and I, for one, would happily modify host-me= ta > and webfinger to require JSON is people feel this strongly about it.**** > > **** > > DEFINING SPECIFIC RESOURCES: Besides specifying a discovery protocol, > WebFinger also defines specific resources and kinds of resources to be us= ed > with that protocol: the "acct" URI scheme, the "acct" Link Relation. > These should be considered on their own merits, but logically should be > decoupled from the discovery protocol into a different document or > documents. It's not clear these features would be needed in OAuth contex= ts. > **** > > ** ** > > I have long argued against the acct URI, but the consensus-based approach > of the IETF has over-ridden me on that one. If you feel similarly, you ar= e > free to voice that opinion.**** > > ** ** > > It shocks me that you're saying that the OAuth WG shouldn't consider > host-meta/webfinger because it defines something that isn't of interest t= o > the OAuth WG. The whole point of my argument at the WG meeting in Paris w= as > that Webfinger and SWD-like protocols are of such consequence to the web = at > large that the interests of the OAuth WG should not be used to define the > parameters for their behaviour.**** > > ** ** > > I'm more convinced that you're using your power within this WG to have SW= D > rubber-stamped so that you can ship OpenID Connect as you've defined it.*= * > ** > > **** > > QUESTIONS**** > > > 1) Aren't these two mechanisms solving pretty much the same problem?**** > > They are solving an overlapping set of problems, but with > very different privacy characteristics, different deployability > characteristics, different security characteristics, and somewhat differe= nt > mechanisms.**** > > ** ** > > Again, I totally disagree with your assessment here, Mike.**** > > **** > > 2) Do we need to have two standards for the same functionality?**** > > No - Simple Web Discovery is sufficient for the OAuth use > cases (and likely for others as well).**** > > ** ** > > I agree with this =96 since SWD is an explicit (though unstated) fork of > Webfinger, there is no need to have two standards.**** > > **** > > 3) Do you guys have a position or comments regarding either one of them?= * > *** > > The functionality in Simple Web Discovery is minimal and > sufficient for the OAuth use cases, whereas some of the functionality and > assumptions made in WebFinger are harmful, both from a privacy and from a > deployability perspective. SWD should proceed to standardization; > WebFinger should not.**** > > ** ** > > I believe Mike has made misleading statements regarding the privacy and > deployability perspective, either intentionally, or because he > fundamentally does not understand the security or deployment scenarios th= at > motivate the decisions.**** > > ** ** > > In summary:**** > > ** ** > > 1. I believe that SWD and Webfinger are essentially the same protocol, > with different authors names at the top.**** > > 2. I don't care which one "wins", though I think that SWD's use of HTTP i= s > questionable, and that the claims of privacy and deployability advantages > offered by SWD are overblown and potentially misleading.**** > > 3. My concerns about SWD apply equally to any concerns anyone would > leverage against Webfinger.**** > > 4. Which is to say, I think we should have one protocol that is defined b= y > an open discussion.**** > > 5. We've had an open discussion on the webfinger list and apps-discuss an= d > in the context of host-meta that the SWD folks have chosen not to engage > with for the past three years.**** > > 6. The OAuth list is *not* the place for this discussion to happen, just > so that Mike Jones can quickly push a spec through the formal process usi= ng > a list that has well-known problems of too-high mail volume and whose top= ic > is unrelated to the goals of Webfinger/SWD.**** > > ** ** > > This is important enough to get right, and getting it wrong will almost > certainly lead to years of incompatibility and frustration, as Stephen > mentioned. I encourage everyone involved to take this seriously, let go o= f > personal attachment and presumptions of dependencies, and consider this > work in an appropriate context (with an inclusive, not exclusive communit= y). > **** > > ** ** > > b.**** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --20cf3071cffa38891e04bdb3e04b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


--20cf3071cffa38891e04bdb3e04b-- From ve7jtb@ve7jtb.com Sun Apr 15 02:17:11 2012 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 EEAFC21F8663 for ; Sun, 15 Apr 2012 02:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEJ039r8W-0P for ; Sun, 15 Apr 2012 02:17:08 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1161F21F8665 for ; Sun, 15 Apr 2012 02:17:07 -0700 (PDT) Received: by bkuw5 with SMTP id w5so3906826bku.31 for ; Sun, 15 Apr 2012 02:17:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=fuACQU0vYf35CJp+C3AG0sDvUFHf23LXzT/+cVjc4D4=; b=Z5cPvVWnTHpsgFZiKqn3ytttKRtGULLzONhPwjnSb2tGdEqr8RmYO3Lbmv2u4k9xf8 23C0a1um1iO9Bvjp7RMEnDi5wDgPKnu7rESxfFBVeXT22BuUTqQZiI9zbDIgVfKbBYJS wOZCh0OKE0PFBALZBv1Ke4noVETg4Hd4OaTAm2n4yGess6i0RfzAZb7dlk6om08Mj4vg tqvhxx08OhUT9iYXcfG/a8c3sXmdHVdQltD1N0THFsDrPaH5v15w7dT9aA0G0C1l7Dhw ekHcFnbiAvq8R61KDW/IDYWmZ+mygXhojxBcAmNhmU24Bm3iw5oIN1Tp6HZuxioUNPxD RG7w== Received: by 10.204.155.143 with SMTP id s15mr2157703bkw.44.1334481426623; Sun, 15 Apr 2012 02:17:06 -0700 (PDT) Received: from [10.0.9.253] ([212.144.56.68]) by mx.google.com with ESMTPS id f5sm25138490bke.9.2012.04.15.02.17.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Apr 2012 02:17:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_AC7B4E60-8987-4482-AA38-6EE1657A2B4C" From: John Bradley In-Reply-To: Date: Sun, 15 Apr 2012 11:16:41 +0200 Message-Id: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4E1F6AAD24975D4BA5B168042967394366465919@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436646671B@TK5EX14MBXC283.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F63@P3PWEX2MB008.ex2.secureserver.net> To: Melvin Carvalho X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQknFWRp+rcgiNZxzs7WEKc4uRMYL8Q1HnyyQ6Jb9K8oPwnmbSTRf7Fw81JBHPihMZd90nl0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Sun, 15 Apr 2012 09:17:11 -0000 --Apple-Mail=_AC7B4E60-8987-4482-AA38-6EE1657A2B4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I look forward to working with Blaine, Mike and others interested on the = apps list. I anticipate being able to find a way forward. Regards John B. On 2012-04-15, at 10:56 AM, Melvin Carvalho wrote: >=20 >=20 > On 15 April 2012 08:21, Eran Hammer wrote: > Tone aside, this is not the first time you distorted process and = technical facts to suit your goals. Just look up some of our exchanges = from a year ago and the transcript of the Prague meeting for highlights. >=20 >=20 > As stephen suggests, could we possibly continue this fascinating = discussion on apps discuss? =20 >=20 > I know people are passionate about this issue, and that's a positive = thing. =20 >=20 > But I think it probably would be most productive, if we could all try = to keep personal attacks to a minimum. > =20 >=20 > =20 >=20 > EH >=20 > =20 >=20 > =20 >=20 > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Mike Jones > Sent: Friday, April 13, 2012 9:18 AM > To: Blaine Cook > Cc: oauth@ietf.org WG >=20 >=20 > Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) >=20 > =20 >=20 > Hi Blaine. I must admit, I=92m pretty surprised by the tone of your = reply. I=92ll say up front that I have absolutely no problem with = anyone disagreeing with me on a technical or tactical basis. If you = think I=92m wrong, have at it. >=20 > =20 >=20 > But I am pretty shocked that you would decide to impugn my motives. = We=92ve only met twice and both times I thought we had really useful and = productive discussions about how to move digital identity on the Web = forward =96 something I believe that we=92re both passionate about. You = don=92t really know me, though, which is apparent from your remarks = below. I believe that those who have worked with me for years would = vouch that I am a forthright and evenhanded standards participant who = listens to all points of view, tries to build a consensus that works, = and produce quality results. >=20 > =20 >=20 > I thought about your note overnight and whether I should reply at all. = I=92m fine with give and take, but I believe that I need to say that if = you read what you wrote below, I think you=92ll agree that the tone you = used was counter-productive and an apology is in order. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > P.S. I=92ll address your technical points below in a separate note at = some point =96 some I agree with and some I don=92t. But I felt that I = needed to address my motives being questioned separately and first. I = hope we can both come out of this with a better understanding of one = another and work together towards the important goals that we both = share. >=20 > =20 >=20 > From: Blaine Cook [mailto:romeda@gmail.com]=20 > Sent: Thursday, April 12, 2012 3:41 PM > To: Mike Jones > Cc: Hannes Tschofenig; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) >=20 > =20 >=20 > On 12 April 2012 17:51, Mike Jones = wrote: >=20 > Thanks for asking these questions Hannes. I'll first provide a brief = feature comparison of Simple Web Discovery and WebFinger and then answer = your questions. >=20 > FEATURE COMPARISON >=20 > RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: SWD returns the = resource location(s) for a specific resource for a specific principal. = WebFinger returns all resources for the principal. The example at = http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2 = "Retrieving a Person's Contact Information" is telling. The WebFinger = usage model seems to be "I'll get everything about you and then fish = through it to decide what to do with it." The protocol assumption that = all WebFinger information must be public is also built into the protocol = where the CORS response header "Access-Control-Allow-Origin: *" is = mandated, per = http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7. = The privacy characteristics of these approaches are very different. = (It's these very same privacy characteristics that led sysadmins to = nearly ubiquitously disabling the fingerd service!) Particularly for = the OAuth use cases, narrow, scoped, and potentially permissioned = responses seem preferable. >=20 > =20 >=20 > This is absolutely false. >=20 > =20 >=20 > SWD provides no privacy whatsoever. SWD makes it somewhat harder to = crawl large numbers of profiles, but it does not incorporate any real = security, and any attempt to suggest that it does is misleading and = deceptive. >=20 > =20 >=20 > Webfinger, like any good HTTP service, is designed to allow access = control using appropriate means. That access control should not be = *bound* to the protocol, in the same way that HTTP does not have any = REQUIRED access control mechanisms, since doing so would severely = restrict future usage of a core protocol. >=20 > =20 >=20 > FUD has no place in a discussion of the technical and social merits of = a protocol. >=20 > =20 >=20 > For what it's worth, my intent with webfinger *from day one, nearly = four years ago*, has been to provide permissioned profile data *using = EXISTING* (or new, where appropriate or necessary, based on *running = code and deployment EXPERIENCE*) access control mechanisms for profile = data. >=20 > =20 >=20 > The idea that there is ONE view of the data is patently false. For = example, depending on who is requesting my profile data, I might return = different contact telephone numbers, and this behaviour is completely = feasible using webfinger. >=20 > =20 >=20 > DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURITY: WebFinger is = built on a "document model", where a single document is returned that = contains multiple resources for a principal. SWD is built on an "API = model", where the location(s) of a particular resource for a principal = are returned. The problem with the document model is that different = parties or services may be authoritative for different resources for a = given principal, and yet all need the rights to edit the resulting = document. This hurts deployability, because document edits then need to = be coordinated among parties that may have different rights and = responsibilities, and may have negative security implications as well. = (Just because I can change your avatar doesn't mean that I should be = able to change your mail server.) >=20 > =20 >=20 > WS-* was built on an API model, and that worked out very well. >=20 > =20 >=20 > APIs and documents on the web are the same thing; how you represent = them behind the scenes is up to you, and that's been a core principle of = the web since shortly after its inception. Suggesting otherwise = profoundly misunderstands how implementation of web services happens. >=20 > =20 >=20 > SWD says nothing of how to update profile data, so the security = concerns here are a total red herring. >=20 > =20 >=20 > REDIRECT FUNCTIONALITY AND DEPLOYABILTY: SWD includes the ability to = redirect some or all SWD requests to another location (possibly = depending upon the specific resource and principal parameters). = Deployers hosting numerous sites for others told the SWD authors that = this functionality is critical for deployability, as it means that the = SWD server for a domain can live in a location outside the domain. = WebFinger is lacking this functionality. Given that OAuth is likely to = be used in hosted environments, this functionality seems pretty = important. >=20 > =20 >=20 > Umm, I'm not even sure what to say to this. host-meta is a static file = that points to a profile server (generally expected to be a dynamic = "API" server) that can be hosted on any domain. >=20 > =20 >=20 > The fact that you're suggesting that this core piece of webfinger = functionality is *missing* seriously undermines my belief that you're = acting in good faith, Mike. >=20 > =20 >=20 > NUMBER OF ROUND TRIPS: WebFinger discoveries for user information = normally require both a host-meta query to retrieve the template and = then a second query to retrieve the user's information. This = functionality is achieved in a single SWD query. >=20 > =20 >=20 > ... at the cost of greater client complexity. A webfinger lookup may = be implemented with the following trivial shell script: >=20 > =20 >=20 > curl -s http://example.com/.well-known/host-meta|awk = "/lrdd/,/template/"|tr -d '\n'|sed -e = "s/^.*template=3D'\([^']*\)'.*$/\1/"|sed -e = "s/{uri}/user@example.com/"|xargs curl -s >=20 > =20 >=20 > so long as your HTTP client properly follows redirects, this approach = will always produce a valid webfinger profile, and if proper caching is = implemented, will only make requests to /.well-known/host-meta when the = document is expired. >=20 > =20 >=20 > SWD, on the other hand, implements a non-HTTP redirect mechanism, = meaning that optimal caching rules can't be obeyed by standard HTTP = clients. Moreover, SWD *requires* conditionals by presenting one code = path for the non-redirect case and one code path for the immediate = response case. >=20 > =20 >=20 > The complexity for client implementations should be foremost in this = work, and the decisions made by SWD don't indicate to me that these = factors have been considered. >=20 > =20 >=20 > Indeed, I wonder why is SWD designed to pre-optimize for presumed = scaling challenges that are faced by only the very largest providers = (namely, the fact that two lookups are required for webfinger instead of = one in the ideal case), when: >=20 > =20 >=20 > 1. Those scaling challenges are simply not real threats. host-meta can = be cached using existing HTTP mechanisms >=20 > 2. The fact that SWD only returns one service definition per request = means that more than one request will often be required to obtain the = necessary information about a user. >=20 > 3. The chances that Google or Microsoft will host dynamic response SWD = services on the gmail.com or hotmail.com domains is next to nil, and = will therefore need to issue redirects anyways. >=20 > =20 >=20 > For smaller providers (e.g., personal domains hosted in static or = rigid environments), hosting a SWD server at = /.well-known/simple-web-discovery may be challenging indeed. Thus, all = clients will need to support the redirect behaviour natively, and for = those who write specs but not code, it is *more* complex to have = conditional behaviour like that than to have a defined flow that is = always followed. >=20 > =20 >=20 > Further, it's more complex for small service providers to host static = content that is invariant and properly cached (e.g., by transparent = proxy caches like varnish and squid) when CGI parameters are appended, = as with SWD. >=20 > =20 >=20 > XML AND JSON VERSUS JSON: WebFinger specifies both XML and JSON = support, whereas SWD specifies only JSON. The SWD position is that it's = simpler to specify only one way of doing the same thing, with JSON being = chosen because it's simpler for developers to use than XML - the same = decision as made for the OAuth specs. >=20 > =20 >=20 > Webfinger only used XRD in the first place to satisfy the OpenID = community. This is infuriating format-fetishism, and misses the point = entirely. JSON is preferred, and I, for one, would happily modify = host-meta and webfinger to require JSON is people feel this strongly = about it. >=20 > =20 >=20 > DEFINING SPECIFIC RESOURCES: Besides specifying a discovery protocol, = WebFinger also defines specific resources and kinds of resources to be = used with that protocol: the "acct" URI scheme, the "acct" Link = Relation. These should be considered on their own merits, but logically = should be decoupled from the discovery protocol into a different = document or documents. It's not clear these features would be needed in = OAuth contexts. >=20 > =20 >=20 > I have long argued against the acct URI, but the consensus-based = approach of the IETF has over-ridden me on that one. If you feel = similarly, you are free to voice that opinion. >=20 > =20 >=20 > It shocks me that you're saying that the OAuth WG shouldn't consider = host-meta/webfinger because it defines something that isn't of interest = to the OAuth WG. The whole point of my argument at the WG meeting in = Paris was that Webfinger and SWD-like protocols are of such consequence = to the web at large that the interests of the OAuth WG should not be = used to define the parameters for their behaviour. >=20 > =20 >=20 > I'm more convinced that you're using your power within this WG to have = SWD rubber-stamped so that you can ship OpenID Connect as you've defined = it. >=20 > =20 >=20 > QUESTIONS >=20 >=20 > 1) Aren't these two mechanisms solving pretty much the same problem? >=20 > They are solving an overlapping set of problems, but = with very different privacy characteristics, different deployability = characteristics, different security characteristics, and somewhat = different mechanisms. >=20 > =20 >=20 > Again, I totally disagree with your assessment here, Mike. >=20 > =20 >=20 > 2) Do we need to have two standards for the same functionality? >=20 > No - Simple Web Discovery is sufficient for the OAuth = use cases (and likely for others as well). >=20 > =20 >=20 > I agree with this =96 since SWD is an explicit (though unstated) fork = of Webfinger, there is no need to have two standards. >=20 > =20 >=20 > 3) Do you guys have a position or comments regarding either one of = them? >=20 > The functionality in Simple Web Discovery is minimal and = sufficient for the OAuth use cases, whereas some of the functionality = and assumptions made in WebFinger are harmful, both from a privacy and = from a deployability perspective. SWD should proceed to = standardization; WebFinger should not. >=20 > =20 >=20 > I believe Mike has made misleading statements regarding the privacy = and deployability perspective, either intentionally, or because he = fundamentally does not understand the security or deployment scenarios = that motivate the decisions. >=20 > =20 >=20 > In summary: >=20 > =20 >=20 > 1. I believe that SWD and Webfinger are essentially the same protocol, = with different authors names at the top. >=20 > 2. I don't care which one "wins", though I think that SWD's use of = HTTP is questionable, and that the claims of privacy and deployability = advantages offered by SWD are overblown and potentially misleading. >=20 > 3. My concerns about SWD apply equally to any concerns anyone would = leverage against Webfinger. >=20 > 4. Which is to say, I think we should have one protocol that is = defined by an open discussion. >=20 > 5. We've had an open discussion on the webfinger list and apps-discuss = and in the context of host-meta that the SWD folks have chosen not to = engage with for the past three years. >=20 > 6. The OAuth list is *not* the place for this discussion to happen, = just so that Mike Jones can quickly push a spec through the formal = process using a list that has well-known problems of too-high mail = volume and whose topic is unrelated to the goals of Webfinger/SWD. >=20 > =20 >=20 > This is important enough to get right, and getting it wrong will = almost certainly lead to years of incompatibility and frustration, as = Stephen mentioned. I encourage everyone involved to take this seriously, = let go of personal attachment and presumptions of dependencies, and = consider this work in an appropriate context (with an inclusive, not = exclusive community). >=20 > =20 >=20 > b. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_AC7B4E60-8987-4482-AA38-6EE1657A2B4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = look forward to working with Blaine, Mike and others interested on the = apps list.

I anticipate being able to find a way = forward.

Regards
John = B.

On 2012-04-15, at 10:56 AM, Melvin Carvalho = wrote:



On 15 April 2012 08:21, = Eran Hammer <eran@hueniverse.com> = wrote:

Tone aside, this is not the first time you = distorted process and technical facts to suit your goals. Just look up = some of our exchanges from a year ago and the transcript of the Prague meeting for = highlights.


As stephen = suggests, could we possibly continue this fascinating discussion on apps = discuss? 

I know people are passionate about this issue, = and that's a positive thing. 

But I think it probably would be most productive, if we could all = try to keep personal attacks to a minimum.
 

 

EH

 

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, April 13, 2012 9:18 AM
To: Blaine Cook
Cc: oauth@ietf.org WG


Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

 

Hi Blaine.  I must admit, I=92m pretty = surprised by the tone of your reply.  I=92ll say up front that I = have absolutely no problem with anyone disagreeing with me on a technical or tactical basis.  If you think I=92m wrong, = have at it.

 

But I am pretty shocked that you would decide to = impugn my motives.  We=92ve only met twice and both times I thought = we had really useful and productive discussions about how to move digital identity on the Web forward =96 something I = believe that we=92re both passionate about.  You don=92t really = know me, though, which is apparent from your remarks below.  I = believe that those who have worked with me for years would vouch that I am a forthright and evenhanded standards participant who listens = to all points of view, tries to build a consensus that works, and = produce quality results.

 

I thought about your note overnight and whether I = should reply at all.  I=92m fine with give and take, but I believe = that I need to say that if you read what you wrote below, I think you=92ll agree that the tone you used was = counter-productive and an apology is in = order.

 

        &nbs= p;            =             &n= bsp;           &nbs= p;            =   -- Mike

 

P.S.  I=92ll address your technical points = below in a separate note at some point =96 some I agree with and some I = don=92t.  But I felt that I needed to address my motives being questioned separately and first.  I hope we can both = come out of this with a better understanding of one another and work = together towards the important goals that we both = share.

 

From: Blaine Cook [mailto:romeda@gmail.com]
Sent: Thursday, April 12, 2012 3:41 PM
To: Mike Jones
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

 

On 12 = April 2012 17:51, Mike Jones <Michael.Jones@microsoft.com> = wrote:

Thanks for asking these questions Hannes. =  I'll first provide a brief feature comparison of Simple Web = Discovery and WebFinger and then answer your questions.

FEATURE COMPARISON

RESULT GRANULARITY AND PRIVACY CHARACTERISTICS:  SWD returns the = resource location(s) for a specific resource for a specific principal. =  WebFinger returns all resources for the principal.  The = example at = http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2 "Retrieving a Person's Contact Information" is telling.  The = WebFinger usage model seems to be "I'll get everything about you and = then fish through it to decide what to do with it."  The protocol assumption that all WebFinger information must be = public is also built into the protocol where the CORS response header = "Access-Control-Allow-Origin: *" is mandated, per = http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7.=  The privacy characteristics of these approaches are very = different.  (It's these very same privacy characteristics that led = sysadmins to nearly ubiquitously disabling the fingerd service!)  Particularly for the OAuth use cases, narrow, scoped, and = potentially permissioned responses seem preferable.

 

This is absolutely false.

 

SWD provides no privacy whatsoever. SWD = makes it somewhat harder to crawl large numbers of profiles, but it does = not incorporate any real security, and any attempt to suggest that it = does is misleading and deceptive.

 

Webfinger, like any good HTTP service, is = designed to allow access control using appropriate means. That access = control should not be *bound* to the protocol, in the same way that HTTP = does not have any REQUIRED access control mechanisms, since doing so would severely restrict future usage of a core = protocol.

 

FUD has no place in a discussion of the = technical and social merits of a protocol.

 

For what it's worth, my intent with = webfinger *from day one, nearly four years ago*, has been to provide = permissioned profile data *using EXISTING* (or new, where appropriate or = necessary, based on *running code and deployment EXPERIENCE*) access control mechanisms for profile data.

 

The idea that there is ONE view of the data = is patently false. For example, depending on who is requesting my = profile data, I might return different contact telephone numbers, and = this behaviour is completely feasible using webfinger.

 

DOCUMENT VERSUS API MODEL, DEPLOYABILITY, = AND SECURITY:  WebFinger is built on a "document model", where a = single document is returned that contains multiple resources for a = principal.  SWD is built on an "API model", where the location(s) of a particular resource for a principal are returned.  The = problem with the document model is that different parties or services = may be authoritative for different resources for a given principal, and = yet all need the rights to edit the resulting document.  This hurts deployability, because document edits then need to be = coordinated among parties that may have different rights and = responsibilities, and may have negative security implications as well. =  (Just because I can change your avatar doesn't mean that I should be able to change your mail server.)

 

WS-* was built on an API model, and that = worked out very well.

 

APIs and documents on the web are the same = thing; how you represent them behind the scenes is up to you, and that's = been a core principle of the web since shortly after its inception. = Suggesting otherwise profoundly misunderstands how implementation of web services happens.

 

SWD says nothing of how to update profile = data, so the security concerns here are a total red = herring.

 

REDIRECT FUNCTIONALITY AND DEPLOYABILTY: =  SWD includes the ability to redirect some or all SWD requests to = another location (possibly depending upon the specific resource and = principal parameters).  Deployers hosting numerous sites for others told the SWD authors that this functionality is critical for = deployability, as it means that the SWD server for a domain can live in = a location outside the domain.  WebFinger is lacking this = functionality.  Given that OAuth is likely to be used in hosted environments, this functionality seems pretty = important.

 

Umm, I'm not even sure what to say to this. = host-meta is a static file that points to a profile server (generally = expected to be a dynamic "API" server) that can be hosted on any = domain.

 

The fact that you're suggesting that this = core piece of webfinger functionality is *missing* seriously undermines = my belief that you're acting in good faith, Mike.

 

NUMBER OF ROUND TRIPS:  WebFinger = discoveries for user information normally require both a host-meta query = to retrieve the template and then a second query to retrieve the user's = information.  This functionality is achieved in a single SWD query.

 

... at the cost of greater client = complexity. A webfinger lookup may be implemented with the following = trivial shell script:

 

curl -s = http://example.com/.well-known/host-meta|awk "/lrdd/,/template/"|tr = -d '\n'|sed -e "s/^.*template=3D'\([^']*\)'.*$/\1/"|sed -e "s/{uri}/user@example.com/"|xargs curl = -s

 

so long as your HTTP client properly follows = redirects, this approach will always produce a valid webfinger profile, = and if proper caching is implemented, will only make requests to = /.well-known/host-meta when the document is expired.

 

SWD, on the other hand, implements a = non-HTTP redirect mechanism, meaning that optimal caching rules can't be = obeyed by standard HTTP clients. Moreover, SWD *requires* conditionals = by presenting one code path for the non-redirect case and one code path for the immediate response case.

 

The complexity for client implementations = should be foremost in this work, and the decisions made by SWD don't = indicate to me that these factors have been = considered.

 

Indeed, I wonder why is SWD designed to = pre-optimize for presumed scaling challenges that are faced by only the = very largest providers (namely, the fact that two lookups are required = for webfinger instead of one in the ideal case), when:

 

1. Those scaling challenges are simply not = real threats. host-meta can be cached using existing HTTP = mechanisms

2. The fact that SWD only returns one = service definition per request means that more than one request will = often be required to obtain the necessary information about a = user.

3. The chances that Google or Microsoft will = host dynamic response SWD services on the gmail.com or hotmail.com domains = is next to nil, and will therefore need to issue redirects = anyways.

 

For smaller providers (e.g., personal = domains hosted in static or rigid environments), hosting a SWD server at = /.well-known/simple-web-discovery may be challenging indeed. Thus, all = clients will need to support the redirect behaviour natively, and for those who write specs but not code, it is *more* complex to = have conditional behaviour like that than to have a defined flow that is = always followed.

 

Further, it's more complex for small service = providers to host static content that is invariant and properly cached = (e.g., by transparent proxy caches like varnish and squid) when CGI = parameters are appended, as with SWD.

 

XML AND JSON VERSUS JSON:  WebFinger = specifies both XML and JSON support, whereas SWD specifies only JSON. =  The SWD position is that it's simpler to specify only one way of = doing the same thing, with JSON being chosen because it's simpler for developers to use than XML - the same decision as made for the = OAuth specs.

 

Webfinger only used XRD in the first place = to satisfy the OpenID community. This is infuriating format-fetishism, = and misses the point entirely. JSON is preferred, and I, for one, would = happily modify host-meta and webfinger to require JSON is people feel this strongly about it.

 

DEFINING SPECIFIC RESOURCES:  Besides = specifying a discovery protocol, WebFinger also defines specific = resources and kinds of resources to be used with that protocol: =  the "acct" URI scheme, the "acct" Link Relation.  These = should be considered on their own merits, but logically should be decoupled from the = discovery protocol into a different document or documents.  It's = not clear these features would be needed in OAuth = contexts.

 

I have long argued against the acct URI, but = the consensus-based approach of the IETF has over-ridden me on that one. = If you feel similarly, you are free to voice that = opinion.

 

It shocks me that you're saying that the = OAuth WG shouldn't consider host-meta/webfinger because it defines = something that isn't of interest to the OAuth WG. The whole point of my = argument at the WG meeting in Paris was that Webfinger and SWD-like protocols are of such consequence to the web at large that the = interests of the OAuth WG should not be used to define the parameters = for their behaviour.

 

I'm more convinced that you're using your = power within this WG to have SWD rubber-stamped so that you can ship = OpenID Connect as you've defined it.

 

QUESTIONS


1) Aren't these two mechanisms solving pretty much the same = problem?

            =   They are solving an overlapping set of problems, but with very = different privacy characteristics, different deployability = characteristics, different security characteristics, and somewhat = different mechanisms.

 

Again, I totally disagree with your = assessment here, Mike.

 

2) Do we need = to have two standards for the same functionality?

            =   No - Simple Web Discovery is sufficient for the OAuth use cases = (and likely for others as well).

 

I agree with this =96 since SWD is an = explicit (though unstated) fork of Webfinger, there is no need to have = two standards.

 

3) Do you = guys have a position or comments regarding either one of = them?

            =   The functionality in Simple Web Discovery is minimal and = sufficient for the OAuth use cases, whereas some of the functionality = and assumptions made in WebFinger are harmful, both from a privacy and = from a deployability perspective.  SWD should proceed to standardization; WebFinger should = not.

 

I believe Mike has made misleading = statements regarding the privacy and deployability perspective, either = intentionally, or because he fundamentally does not understand the = security or deployment scenarios that motivate the = decisions.

 

In summary:

 

1. I believe that SWD and Webfinger are = essentially the same protocol, with different authors names at the = top.

2. I don't care which one "wins", though I = think that SWD's use of HTTP is questionable, and that the claims of = privacy and deployability advantages offered by SWD are overblown and = potentially misleading.

3. My concerns about SWD apply equally to = any concerns anyone would leverage against Webfinger.

4. Which is to say, I think we should have = one protocol that is defined by an open discussion.

5. We've had an open discussion on the = webfinger list and apps-discuss and in the context of host-meta that the = SWD folks have chosen not to engage with for the past three = years.

6. The OAuth list is *not* the place for = this discussion to happen, just so that Mike Jones can quickly push a = spec through the formal process using a list that has well-known = problems of too-high mail volume and whose topic is unrelated to the goals of Webfinger/SWD.

 

This is important enough to get right, and = getting it wrong will almost certainly lead to years of incompatibility = and frustration, as Stephen mentioned. I encourage everyone involved to = take this seriously, let go of personal attachment and presumptions of dependencies, and consider this work in an = appropriate context (with an inclusive, not exclusive = community).

 

b.


_______________________________________________
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

= --Apple-Mail=_AC7B4E60-8987-4482-AA38-6EE1657A2B4C-- From sakimura@gmail.com Sun Apr 15 02:19:09 2012 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 F205521F8715 for ; Sun, 15 Apr 2012 02:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9uatlW5JVzt for ; Sun, 15 Apr 2012 02:19:08 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5AD21F870A for ; Sun, 15 Apr 2012 02:18:58 -0700 (PDT) Received: by bkuw5 with SMTP id w5so3907326bku.31 for ; Sun, 15 Apr 2012 02:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:date:message-id:subject:to :content-type; bh=uupHruHR6qQc8KyRJC2MEjlGBF7lHRpHsBFitdqt4NM=; b=qdSvmuCZzlrrsEK84pXqDFiXUERPLFH1/ntMJ99E2TfciOfi4znljGYyl1EI9OPDU8 1eEaDByT/s5yxaYS3W2YLHGJq+Mf03aGalBy7RQkcRkNGXwgSZAQoTsrY2KV9+rCJd3R iYRcUxjnlQxC0d3hNSIw7lc3F8py9Q+qH4LIPHKVR5syHPWpPgNyfBydlGPR04cUr6Ht aEyzGRxOv5xol7hAG1yhGZiPwsL1vWb0kzeqY5hXTgIaxHqOshfftnxzVI0SmBCmTb/c 5g9GBLO7kzqMNWttXMunpDtJUIx6HyukTgoFDSLpS+dMELpCdu+rT7XTuyaqlcTu81BS lIyw== Received: by 10.204.156.65 with SMTP id v1mr2229493bkw.109.1334481537315; Sun, 15 Apr 2012 02:18:57 -0700 (PDT) References: <20120415052622.28102.369.idtracker@ietfa.amsl.com> From: Nat Sakimura Mime-Version: 1.0 (1.0) Date: Sun, 15 Apr 2012 11:18:56 +0200 Message-ID: <-6098681674147711493@unknownmsgid> To: oauth Content-Type: multipart/alternative; boundary=0015175cb66efdb3e104bdb4316a Subject: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-requrl-02.txt 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: Sun, 15 Apr 2012 09:19:09 -0000 --0015175cb66efdb3e104bdb4316a Content-Type: text/plain; charset=ISO-8859-1 A new version of I-D, draft-sakimura-oauth-requrl-02.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. Filename: draft-sakimura-oauth-requrl Revision: 02 Title: Request by JSON ver.1.0 for OAuth 2.0 Creation date: 2012-04-15 WG ID: Individual Submission Number of pages: 9 Abstract: The authorization request in OAuth 2.0 utilizes query parameter serizalization. This specification defines the authorization request using JWT serialization. The request is sent through request parameter or by reference through request_uri that points to the JWT serialized authorization request. The IETF Secretariat --0015175cb66efdb3e104bdb4316a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A new version of I-D, draft-sakimura-oauth-requrl-02.txt has = been successfully submitted by Nat Sakimura and posted to the IETF reposito= ry.

Filename: =A0 =A0 draft-sakimura-oauth-requrl
Revision: =A0 =A0 02
Title: =A0 =A0 =A0 =A0 Request by JSON ver.= 1.0 for OAuth 2.0
Creation date: =A0 =A0 2012-04-15
WG = ID: =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 9

Abstract:
=A0 Th= e authorization request in OAuth 2.0 utilizes query parameter
=A0= serizalization. =A0This specification defines the authorization request
=A0 using JWT serialization. =A0The request is sent through request
=A0 parameter or by reference through request_uri that points to th= e
=A0 JWT serialized authorization request.

<= div>


The IETF Secretariat
--0015175cb66efdb3e104bdb4316a-- From pelle@kodfabrik.se Sun Apr 15 08:11:54 2012 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 9652921F87AE for ; Sun, 15 Apr 2012 08:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXcInb5M94iN for ; Sun, 15 Apr 2012 08:11:54 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id BFAA921F87A9 for ; Sun, 15 Apr 2012 08:11:53 -0700 (PDT) Received: by qafi31 with SMTP id i31so6436510qaf.15 for ; Sun, 15 Apr 2012 08:11:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=85S8GLqo437gvgWM2dEdQQOyShkOVyRvpWizcRp5dgk=; b=pVEXKdmKLNJbSkiX1TSzKPYHx6RnhqbkFKtgdkOzXC/bxXz6TmmVzYFEhcnccvnGLU mH0FwWTwsRDBXTbb1lmQ3LPhvnYCi8Zk14FDs3lt/IRk3ZAW/fclKzy82Fx2Gtv0MNBV MGzr0Gq3CYGMOhkZcmKfzNR2lqu5pZZCSOnIIVH2UMr7MneLP0yUGy0IrPKJpz8dds8U Rp4Nj7RhfOna6WjV6ZupcmAuF4xwYX9FR+pRvIeapHu5s3w1ORP20oNgSnSMazffy9VB O+UDzBsA96xjgxsSDFQWxtiJIL91fnVFRYFv9RO4xps//1Hr4zEdTzSxFosviz6P8ezR qpIg== MIME-Version: 1.0 Received: by 10.229.137.149 with SMTP id w21mr3411708qct.27.1334502712794; Sun, 15 Apr 2012 08:11:52 -0700 (PDT) Received: by 10.229.133.132 with HTTP; Sun, 15 Apr 2012 08:11:52 -0700 (PDT) In-Reply-To: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> Date: Sun, 15 Apr 2012 17:11:52 +0200 Message-ID: From: Pelle Wessman To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=00235452f83425e11504bdb9202b X-Gm-Message-State: ALoCoQkr5e1T8cwnX8C0TnBNrJO1ZI8paTUOVoEfGvKZY79q27C4OIC1WpibCX7uBPU4909UUQeI Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) 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: Sun, 15 Apr 2012 15:11:54 -0000 --00235452f83425e11504bdb9202b Content-Type: text/plain; charset=ISO-8859-1 Could someone please explain to me how Webfinger solves the same problem as SWD? Isn't Webfinger just defining a way to discover data about a user using the "Web Host Metadata" discovery mechanism that's already defined in RFC 6415? While SWD instead defines an entirely new discovery mechanism without really defining how to use it to discover data about a user? To me it seems like SWD instead solves the same problem as RFC 6415? What am I missing? I personally still prefer the original Webfinger proposal that didn't really define anything extra but just showed how to use RFC 6415 to discover data about users. The way it worked made it, as I see it, easy to expose your data and to consume it. I don't really see a point in the recent additions to the Webfinger draft - anything beyond specifying the acct URL scheme and a few basic link relations seems unneeded and out of scope to me and just complicates things. / Pelle Wessman On Thu, Apr 12, 2012 at 1:00 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > those who had attended the last IETF meeting may have noticed the ongoing > activity in the 'Applications Area Working Group' regarding Web Finger. > We had our discussion regarding Simple Web Discovery (SWD) as part of the > re-chartering process. > > Here are the two specifications: > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 > > Now, the questions that seems to be hanging around are > > 1) Aren't these two mechanisms solving pretty much the same problem? > 2) Do we need to have two standards for the same functionality? > 3) Do you guys have a position or comments regarding either one of them? > > Ciao > Hannes > > PS: Please also let me know if your view is: "I don't really know what all > this is about and the documents actually don't provide enough requirements > to make a reasonable judgement about the solution space." > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00235452f83425e11504bdb9202b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Could someone please explain to me how Webfinger solves the same problem as= SWD?

Isn't Webfinger just defining a way to discover data about= a user using the "Web Host Metadata" discovery mechanism that= 9;s already defined in RFC 6415? While SWD instead defines an entirely new = discovery mechanism without really defining how to use it to discover data = about a user?

To me it seems like SWD instead solves the same problem as RFC 6415? Wh= at am I missing?

I personally still prefer the original Webfinger pr= oposal that didn't really define anything extra but just showed how to = use RFC 6415 to discover data about users. The way it worked made it, as I = see it, easy to expose your data and to consume it. I don't really see = a point in the recent additions to the Webfinger draft - anything beyond sp= ecifying the acct URL scheme and a few basic link relations seems unneeded = and out of scope to me and just complicates things.

/ Pelle Wessman


On Thu, Apr 12, 2= 012 at 1:00 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

those who had attended the last IETF meeting may have noticed the ongoing a= ctivity in the 'Applications Area Working Group' regarding Web Fing= er.
We had our discussion regarding Simple Web Discovery (SWD) as part of the r= e-chartering process.

Here are the two specifications:
http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03<= /a>
http://tools.ietf.org/html/draft-jones-simple-web-discove= ry-02

Now, the questions that seems to be hanging around are

=A01) Aren't these two mechanisms solving pretty much the same problem?=
=A02) Do we need to have two standards for the same functionality?
=A03) Do you guys have a position or comments regarding either one of them?=

Ciao
Hannes

PS: Please also let me know if your view is: "I don't really know = what all this is about and the documents actually don't provide enough = requirements to make a reasonable judgement about the solution space."=




_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--00235452f83425e11504bdb9202b-- From hannes.tschofenig@gmx.net Sun Apr 15 09:01:19 2012 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 0762821F87EF for ; Sun, 15 Apr 2012 09:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FR822yxjZm8D for ; Sun, 15 Apr 2012 09:01:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D5AE621F87EC for ; Sun, 15 Apr 2012 09:01:17 -0700 (PDT) Received: (qmail invoked by alias); 15 Apr 2012 16:01:15 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp001) with SMTP; 15 Apr 2012 18:01:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX180oIw4Zns0AKenXbZidHTGOIeLg+wl/ssmh5kwkr sTeDWdW1+Q6wh2 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F47@P3PWEX2MB008.ex2.secureserver.net> Date: Sun, 15 Apr 2012 19:01:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6760C38E-7C0C-412F-A285-8F4CB2858F30@gmx.net> References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F47@P3PWEX2MB008.ex2.secureserver.net> To: Eran Hammer X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration 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: Sun, 15 Apr 2012 16:01:19 -0000 Hi Eran,=20 you are saying that you are not interested in the dynamic client = registration work and that's OK. There are, however, a couple of other = folks in the group who had expressed interest to work on it, to review = and to implement it.=20 Note also that the discovery and the dynamic client registration is = different from each other; there is a relationship but they are = nevertheless different.=20 Ciao Hannes PS: Moving the Simple Web Discovery to the Apps area working group does = not mean that it will not be done. On the contrary there will be work = happing and we are just trying to figure out what the difference between = SWD and WebFinger is.=20 On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote: > I'd like to see 'Dynamic Client Registration' removed from the charter = along with SWD for the sole reason that figuring out a generic discovery = mechanism is going to take some time and this WG has enough other work = to focus on while that happens elsewhere. I expect this to come back in = the next round with much more deployment experience and discovery = clarity. >=20 > EH >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Hannes Tschofenig >> Sent: Friday, April 13, 2012 7:36 AM >> To: oauth@ietf.org WG >> Subject: [OAUTH-WG] Dynamic Client Registration >>=20 >> Hi all, >>=20 >> at the IETF#83 OAuth working group meeting we had some confusion = about >> the Dynamic Client Registration and the Simple Web Discovery item. I = just >> listened to the audio recording again. >>=20 >> With the ongoing mailing list discussion regarding WebFinger vs. = Simple Web >> Discovery I hope that folks had a chance to look at the documents = again and >> so the confusion of some got resolved. >>=20 >> I believe the proposed new charter item is sufficiently clear with = regard to >> the scope of the work. Right? >> Here is the item again: >> " >> Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the = IESG for >> consideration as a Proposed Standard >>=20 >> [Starting point for the work will be >> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg >> ] >> " >>=20 >> Of course there there is a relationship between Simple Web Discovery = (or >> WebFinger) and the dynamic client registration since the client first = needs to >> discover the client registration endpoint at the authorization server = before >> interacting with it. >>=20 >> Now, one thing that just came to my mind when looking again at draft- >> hardjono-oauth-dynreq was the following: Could the Client = Registration >> Request and Response protocol exchange could become a profile of the >> SCIM protocol? In some sense this exchange is nothing else than = provisioning >> an account at the Authorization Server (along with some meta-data). >>=20 >> Is this too far fetched? >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sun Apr 15 09:06:14 2012 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 5ABA921F8744 for ; Sun, 15 Apr 2012 09:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTojKxZLswHV for ; Sun, 15 Apr 2012 09:06:13 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1F87921F8743 for ; Sun, 15 Apr 2012 09:06:05 -0700 (PDT) Received: (qmail invoked by alias); 15 Apr 2012 16:06:01 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp016) with SMTP; 15 Apr 2012 18:06:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+tRENxnE2tjIx6kdlopCsZG5bSsFd/3kX3SXKi/c VvBfeh9EwriTHh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1334419265.3552.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Sun, 15 Apr 2012 19:06:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <997D46FA-F78A-4940-9B56-49C4D2473F01@gmx.net> References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> <3E72A308-75EE-4F5C-96CC-A51F0B81106A@xmlgrrl.com> <1334419265.3552.YahooMailNeo@web31816.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration 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: Sun, 15 Apr 2012 16:06:14 -0000 Bill, I actually do not think that the security of either SCIM or this work is = particularly challenging.=20 For SCIM I assume that there is a close relationship between the SCIM = client and a SCIM server (as it is common in an enterprise or single = administrative domain scenario).=20 For the dynamic registration I assume that there is no relationship = between the two in the worst case and therefore this turns into a leap = of faith type of provisioning.=20 I may be completely wrong here but that's the impression I have at the = moment.=20 In any case, these questions are something to deal with once we have = started the work. At the moment we are still attempting to finalize the = re-chartering.=20 Ciao Hannes On Apr 14, 2012, at 7:01 PM, William Mills wrote: > Yeah, SCIM as a way to federate and distribute info like this seems = sane, with extensions for the data items we need here. The hard part is = still around the security stuff which they have not dealt with yet, and = that's going to be a blocker until it's solved. Authority to update = elemnts or namespaces is going to be needed, and that's a hard problem. >=20 > -bill >=20 > From: Eve Maler > To: Hannes Tschofenig =20 > Cc: "oauth@ietf.org WG" =20 > Sent: Friday, April 13, 2012 6:29 PM > Subject: Re: [OAUTH-WG] Dynamic Client Registration >=20 > Hi Hannes-- That's kind of a cool idea. You're right that it's a = "client account" of sorts. At least worth exploring, I'd say, unless a = SCIM expert pipes up with a reason why not. >=20 > Eve >=20 > On 13 Apr 2012, at 7:36 AM, Hannes Tschofenig wrote: >=20 > > Hi all,=20 > >=20 > > at the IETF#83 OAuth working group meeting we had some confusion = about the Dynamic Client Registration and the Simple Web Discovery item. = I just listened to the audio recording again.=20 > >=20 > > With the ongoing mailing list discussion regarding WebFinger vs. = Simple Web Discovery I hope that folks had a chance to look at the = documents again and so the confusion of some got resolved. =20 > >=20 > > I believe the proposed new charter item is sufficiently clear with = regard to the scope of the work. Right?=20 > > Here is the item again: > > " > > Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to = the IESG for consideration as a Proposed Standard > >=20 > > [Starting point for the work will be=20 > > http://tools.ietf.org/html/draft-hardjono-oauth-dynreg > > ]=20 > > " > >=20 > > Of course there there is a relationship between Simple Web Discovery = (or WebFinger) and the dynamic client registration since the client = first needs to discover the client registration endpoint at the = authorization server before interacting with it.=20 > >=20 > > Now, one thing that just came to my mind when looking again at = draft-hardjono-oauth-dynreq was the following: Could the Client = Registration Request and Response protocol exchange could become a = profile of the SCIM protocol? In some sense this exchange is nothing = else than provisioning an account at the Authorization Server (along = with some meta-data). > >=20 > > Is this too far fetched?=20 > >=20 > > Ciao > > Hannes > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 From eran@hueniverse.com Sun Apr 15 13:36:03 2012 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 2825A21F8797 for ; Sun, 15 Apr 2012 13:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3gPBXQK7QqJ for ; Sun, 15 Apr 2012 13:36:02 -0700 (PDT) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7A02C21F8796 for ; Sun, 15 Apr 2012 13:36:02 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id yLc11i0010EuLVk01Lc1Zw; Sun, 15 Apr 2012 13:36:01 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Sun, 15 Apr 2012 13:36:01 -0700 From: Eran Hammer To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Dynamic Client Registration Thread-Index: AQHNGYLIAhnVBxyYNEuwmb5Seq6ic5abalPQgAEZ9wD//9bm0A== Date: Sun, 15 Apr 2012 20:36:01 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE92E4@P3PWEX2MB008.ex2.secureserver.net> References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F47@P3PWEX2MB008.ex2.secureserver.net> <6760C38E-7C0C-412F-A285-8F4CB2858F30@gmx.net> In-Reply-To: <6760C38E-7C0C-412F-A285-8F4CB2858F30@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration 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: Sun, 15 Apr 2012 20:36:03 -0000 Where did I say I'm not interested in this work?! All I was saying is that it would be better to postpone it until the discov= ery layer, which this draft clearly relies upon, is a bit clearer. I would = be satisfied with a simple note stating that if the discovery work at the A= PP area isn't complete, the WG may choose to delay work on this document un= til ready. EH > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Sunday, April 15, 2012 9:01 AM > To: Eran Hammer > Cc: Hannes Tschofenig; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Dynamic Client Registration >=20 > Hi Eran, >=20 > you are saying that you are not interested in the dynamic client registra= tion > work and that's OK. There are, however, a couple of other folks in the gr= oup > who had expressed interest to work on it, to review and to implement it. >=20 > Note also that the discovery and the dynamic client registration is diffe= rent > from each other; there is a relationship but they are nevertheless differ= ent. >=20 > Ciao > Hannes >=20 > PS: Moving the Simple Web Discovery to the Apps area working group does > not mean that it will not be done. On the contrary there will be work hap= ping > and we are just trying to figure out what the difference between SWD and > WebFinger is. >=20 > On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote: >=20 > > I'd like to see 'Dynamic Client Registration' removed from the charter = along > with SWD for the sole reason that figuring out a generic discovery mechan= ism > is going to take some time and this WG has enough other work to focus on > while that happens elsewhere. I expect this to come back in the next roun= d > with much more deployment experience and discovery clarity. > > > > EH > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Hannes Tschofenig > >> Sent: Friday, April 13, 2012 7:36 AM > >> To: oauth@ietf.org WG > >> Subject: [OAUTH-WG] Dynamic Client Registration > >> > >> Hi all, > >> > >> at the IETF#83 OAuth working group meeting we had some confusion > >> about the Dynamic Client Registration and the Simple Web Discovery > >> item. I just listened to the audio recording again. > >> > >> With the ongoing mailing list discussion regarding WebFinger vs. > >> Simple Web Discovery I hope that folks had a chance to look at the > >> documents again and so the confusion of some got resolved. > >> > >> I believe the proposed new charter item is sufficiently clear with > >> regard to the scope of the work. Right? > >> Here is the item again: > >> " > >> Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the > >> IESG for consideration as a Proposed Standard > >> > >> [Starting point for the work will be > >> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg > >> ] > >> " > >> > >> Of course there there is a relationship between Simple Web Discovery > >> (or > >> WebFinger) and the dynamic client registration since the client first > >> needs to discover the client registration endpoint at the > >> authorization server before interacting with it. > >> > >> Now, one thing that just came to my mind when looking again at draft- > >> hardjono-oauth-dynreq was the following: Could the Client > >> Registration Request and Response protocol exchange could become a > >> profile of the SCIM protocol? In some sense this exchange is nothing > >> else than provisioning an account at the Authorization Server (along w= ith > some meta-data). > >> > >> Is this too far fetched? > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Mon Apr 16 04:33:40 2012 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 E89E721F8623 for ; Mon, 16 Apr 2012 04:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEK0MCVBFKtW for ; Mon, 16 Apr 2012 04:33:40 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id 26BC821F85FB for ; Mon, 16 Apr 2012 04:33:39 -0700 (PDT) Received: from mail-vb0-f52.google.com ([209.85.212.52]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKT4wDkdf2j5EXXFAAON7n1dgjc1/Toej3@postini.com; Mon, 16 Apr 2012 04:33:40 PDT Received: by vbzb23 with SMTP id b23so5953350vbz.39 for ; Mon, 16 Apr 2012 04:33:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Om0BfMjsj1+1KptMfN7hv1HESvtIC926GQzzizBh330=; b=A/56D6+XCwW1jqdJ5/9WGi+Han2OY6ixwK9pnIIo0RN3nTJwXPbimnKRTs5qEesfgl AfNLMG7LnnANbCy9blJEJmfLeZJ78y2fQBrMox5g3N6Wip1E+VhEYTpBRVTs4w2sj+0+ lupG6Co9A01F6wmlqvupz68Gwd6yRuLN8U9J3bUgv9rzXoDrq579/nf+CroRxzNiWgtu vBk8ULqG41ws0MAzIuE75Z8mJ6bbnQ9uykn1S8nBYxtuO5nciHhJYC+zOmISGW/NLId4 g9mos22UBem8054I6vxYjvPk3ODIXUkjzcJqZ4g+ehoy0ecg7yYGW0ehm3PDyjtrqF5j oazA== Received: by 10.220.117.203 with SMTP id s11mr5822916vcq.33.1334576016928; Mon, 16 Apr 2012 04:33:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.38.104 with HTTP; Mon, 16 Apr 2012 04:33:06 -0700 (PDT) In-Reply-To: <330ED93F-87B0-4225-A6C8-100F5FEE450C@ve7jtb.com> References: <4ad901cd1a39$9dd5cdba$0c209f0a@nsnintra.net> <330ED93F-87B0-4225-A6C8-100F5FEE450C@ve7jtb.com> From: Brian Campbell Date: Mon, 16 Apr 2012 05:33:06 -0600 Message-ID: To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl1UNd6T77ErfrMJEw2Vh+AGEnk0TT9JvXxCf4xpEGJ4/eRzCAhhZt9szl6D3eS3cRgI5uH Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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, 16 Apr 2012 11:33:41 -0000 The Ping doc was sent a while back on a different thread about re-charting: http://www.ietf.org/mail-archive/web/oauth/current/msg08607.ht= ml I should probably have my people (aka Paul) submit it as an actual I-D? On Sat, Apr 14, 2012 at 8:25 AM, John Bradley wrote: > There is a Ping document. =A0I was talking to openAM/ForgeRock today abou= t a similar endpoint they are working on. > > Justin can submit his and I will look for the others. > > John B. > > Sent from my iPhone > > On 2012-04-14, at 2:28 PM, "Tschofenig, Hannes (NSN - FI/Espoo)" wrote: > >> >> OK, but > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From hannes.tschofenig@gmx.net Mon Apr 16 04:55:44 2012 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 4E66C21F86B7 for ; Mon, 16 Apr 2012 04:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vh3T4MTgwwt for ; Mon, 16 Apr 2012 04:55:44 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 705A521F8687 for ; Mon, 16 Apr 2012 04:55:43 -0700 (PDT) Received: (qmail invoked by alias); 16 Apr 2012 11:55:41 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp035) with SMTP; 16 Apr 2012 13:55:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+6n3wHgCG6f6mckOu1klKPvwPY6xtZ6DeHWQErCs fyUvpjiebMDifF From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Apr 2012 14:55:41 +0300 Message-Id: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] IIW and OAuth 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, 16 Apr 2012 11:55:44 -0000 Hi guys,=20 I was wondering how many of you will be at the upcoming IIW in Mountain = View (or for some other event). IIW will run from Tuesday (May 1st) to = Thursday (May 3rd).=20 I thought it might be good to useful to get together on the Friday after = the IIW event for a OAuth breakfast chat. I am sure that there are still a couple of topics that require = brainstorming. =20 Drop me a message if you are able and interested. Ciao Hannes PS: Please do not forget to read the Assertion specs so that we can get = them out of the door.=20 (And thanks to those who have already read them.) From ve7jtb@ve7jtb.com Mon Apr 16 04:59:19 2012 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 3136C21F86B7 for ; Mon, 16 Apr 2012 04:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8-qULHuKa8v for ; Mon, 16 Apr 2012 04:59:18 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5217721F86A8 for ; Mon, 16 Apr 2012 04:59:18 -0700 (PDT) Received: by bkuw5 with SMTP id w5so4580909bku.31 for ; Mon, 16 Apr 2012 04:59:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=j1ipJh8YAJFolicnNTNFA6EwkbzOEof1AZ6wTWkBQRA=; b=LiPpZkLjb9jJJksW/DUiWEscQXBynNVg410cY1UY7lYEhFxW5kLBwQRNIW31NtUh8y 4m/Pw+u+sFfg4/AlIHOqt0GvQ7mpR3v2zbvN6voteviXmEfth9kmmLJm2Lha8Ojekpmn u2N12hg0hrzdUZiOSWgTSG7ZwA88fewNW3uqd1DAMibLOqG9XlW6htw402yN8/xX85Sz DeqJW6hNvqALO944RFmNPNleYLrUoKYfBOL7xFXFupx89xJWN9rY9n4lR4zP6r9VL0L1 Fsh7EkHf8ZYFB/Y5sYAtKaKltT3cOHNaXuGEAlv8WLbG5k5/5J6J3G8WeRJLTSuwTfno HFoQ== Received: by 10.205.120.131 with SMTP id fy3mr3330522bkc.90.1334577557289; Mon, 16 Apr 2012 04:59:17 -0700 (PDT) Received: from [192.168.2.2] ([212.144.56.68]) by mx.google.com with ESMTPS id iv11sm31029985bkc.16.2012.04.16.04.59.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 04:59:16 -0700 (PDT) References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> In-Reply-To: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-F1002B51-B07B-411A-97C4-40D05A626A74; protocol="application/pkcs7-signature" Message-Id: <06E6AE8D-B231-417B-BE16-3B0FF53F2DB8@ve7jtb.com> X-Mailer: iPad Mail (9B176) From: John Bradley Date: Mon, 16 Apr 2012 13:59:35 +0200 To: Hannes Tschofenig X-Gm-Message-State: ALoCoQklsAh/6/PaZ4NnhGJogKKmBRIPZBzKr8BXz5DSi3WbJgGBsyBCvqO+BXIaiKi2utpKKqwM Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IIW and OAuth 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, 16 Apr 2012 11:59:19 -0000 --Apple-Mail-F1002B51-B07B-411A-97C4-40D05A626A74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can do.=20 Sent from my iPad On 2012-04-16, at 1:55 PM, Hannes Tschofenig wro= te: > Hi guys,=20 >=20 > I was wondering how many of you will be at the upcoming IIW in Mountain Vi= ew (or for some other event). IIW will run from Tuesday (May 1st) to Thursda= y (May 3rd).=20 >=20 > I thought it might be good to useful to get together on the Friday after t= he IIW event for a OAuth breakfast chat. > I am sure that there are still a couple of topics that require brainstormi= ng. =20 >=20 > Drop me a message if you are able and interested. >=20 > Ciao > Hannes >=20 > PS: Please do not forget to read the Assertion specs so that we can get th= em out of the door.=20 > (And thanks to those who have already read them.) >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-F1002B51-B07B-411A-97C4-40D05A626A74 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTYxMTU5MzdaMCMGCSqGSIb3DQEJBDEWBBTSjtbO IMYzV7tBdJX0j8/X9taeATCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQAzsEtIVMOUv6tjHO7jOtqgkICC8R4gYfJ3tzIJ VqpOjYVHK1JoYZKguwgHhPHlCI5Jhr5g5AW5vmd6GmEe7Ec4pZ4NRPFcCF74RyCPTKrH2ZpY9MRC c1T2JMOOqSvBPWohiUjPkfMjyJdC69D3X9+K1782jvh2rv7K0VvIsrXdD+CvEh/cKTOoX51eNi/c SkwTah93LrSfC8XVauKSQyID61MFhk3CfI7PYtbBDaIZhfDwbKM97iOQ/1yy2Rpt4H/sAf7gAA4Q AkYpTI7uwnbrl6KUMknm8laWqbQTdlDJVqKzDb1Oh1W8X3NLCR5PVqq+Cr8Ou50CZSKRt30osxWn AAAAAAAA --Apple-Mail-F1002B51-B07B-411A-97C4-40D05A626A74-- From ietf-ipr@ietf.org Thu Apr 12 14:28:40 2012 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 DD8E321F8799; Thu, 12 Apr 2012 14:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur+cfCtnspF2; Thu, 12 Apr 2012 14:28:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E49E21F8789; Thu, 12 Apr 2012 14:28:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: mbj@microsoft.com, dick.hardt@gmail.com, dr@fb.com X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120412212840.1590.93263.idtracker@ietfa.amsl.com> Date: Thu, 12 Apr 2012 14:28:40 -0700 X-Mailman-Approved-At: Mon, 16 Apr 2012 07:47:37 -0700 Cc: derek@ihtfp.com, oauth@ietf.org, ipr-announce@ietf.org Subject: [OAUTH-WG] IPR Disclosure: John Klensin's Statement about IPR related to draft-ietf-oauth-v2-bearer-18 belonging to Soverain Software LLC 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: Thu, 12 Apr 2012 21:28:41 -0000 Dear Michael Jones, Dick Hardt, David Recordon: An IPR disclosure that pertains to your Internet-Draft entitled "The OAuth= 2.0 Authorization Protocol: Bearer Tokens" (draft-ietf-oauth-v2-bearer) was submitted to the IETF Secretariat on 2012-04-12 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1752/). The title of the IPR disclosure is "John Klensin's Statement about IPR related to draft-ietf-oauth-v2-bearer-18 belonging to Soverain Software LLC.""); The IETF Secretariat From wmills@yahoo-inc.com Mon Apr 16 08:10:11 2012 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 1DE0B21F86A5 for ; Mon, 16 Apr 2012 08:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.392 X-Spam-Level: X-Spam-Status: No, score=-16.392 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFo2cSmEGwLy for ; Mon, 16 Apr 2012 08:10:10 -0700 (PDT) Received: from nm3-vm0.bullet.mail.ac4.yahoo.com (nm3-vm0.bullet.mail.ac4.yahoo.com [98.139.53.204]) by ietfa.amsl.com (Postfix) with SMTP id 05E3221F86A1 for ; Mon, 16 Apr 2012 08:10:09 -0700 (PDT) Received: from [98.139.52.188] by nm3.bullet.mail.ac4.yahoo.com with NNFMP; 16 Apr 2012 15:10:06 -0000 Received: from [98.139.52.159] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 16 Apr 2012 15:10:06 -0000 Received: from [127.0.0.1] by omp1042.mail.ac4.yahoo.com with NNFMP; 16 Apr 2012 15:10:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 966748.76551.bm@omp1042.mail.ac4.yahoo.com Received: (qmail 74127 invoked by uid 60001); 16 Apr 2012 15:10:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334589006; bh=HkaYpDVnscth2V79mjoglf7+f+yDmvuAbrBClRBTojE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=DR8GiWc+MVNgLyf9L5DDw0q3WjbFMDzf3uuDsGhNJtj+twJh8H4TtA7/StxH/TJjGxiQjcrrU0Qa29Ncdu+WPg9AqINMod34nkSLvEBdzx/yy7/+EE/Y4SXvdL/t/u7tTWR2m9diP8RfxMaasv8DwzFwBxsoVSPqjLgEz6Z4hGY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=NDQT/l/yFqmfOoTL0YHgU14zdqiyUewhDcU1QnP/g4YO2PyUS/OMjOJPqYStK86fkseq8DRX9Z69i3S3dF37YgWkjvTeH02wAWezSJHQeB7ulbdr8XmQy30md8AFQX6oj5LTE6BmJYWXuYs72TT+pV7uOOTVX3i8YGm6kRuuIKc=; X-YMail-OSG: twFmawgVM1kIn.dQVB6kI00Vjo0hg4d2kdT504c4ugaWJoM V3g3FvZpGJDZga.lcsOrAjRNl7SLw.2OQk8CYNZdJiQKy_4bRry5dJjQ1NMZ szvJ6Yj5NWTKLnYpN_NHzcNlbh6A67n61UsVJkLqSnAJjfQcMdVSnGlmJIwb OaVtYlARGDWRVXH2fE7QlWys1sI9jEbHL6YUkvU_EqHSl9eLh.g6m0crF_6J OPZZ0x3Ic_rjm832m4x7857iWoEW68ST.0LhWlE_.0z04L1BCWS9dPv.eTLo 91j8e_.6hkVIrvmzxAMnsftrmqUHSgCvAYNNHpZ7VqDgcnFtnd3KqNHV8vG4 p_RhKya7Omp6kYGExREE39agn3xro3qsMv_POxJLj4AqL6lpLss5LY2fS1hA xaGoF64umRACl4lxd48SIGmRVFvDx Received: from [99.31.212.42] by web31802.mail.mud.yahoo.com via HTTP; Mon, 16 Apr 2012 08:10:06 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> Message-ID: <1334589006.13306.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Mon, 16 Apr 2012 08:10:06 -0700 (PDT) From: William Mills To: Hannes Tschofenig , "oauth@ietf.org WG" In-Reply-To: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-1230859682-1334589006=:13306" Subject: Re: [OAUTH-WG] IIW and OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 15:10:11 -0000 ---1036955950-1230859682-1334589006=:13306 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I am planning to.=0A=0A-bill=0A=0A=0A=0A=0A>_______________________________= _=0A> From: Hannes Tschofenig =0A>To: "oauth@iet= f.org WG" =0A>Sent: Monday, April 16, 2012 4:55 AM=0A>Subj= ect: [OAUTH-WG] IIW and OAuth=0A> =0A>Hi guys, =0A>=0A>I was wondering how = many of you will be at the upcoming IIW in Mountain View (or for some other= event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd). =0A>=0A= >I thought it might be good to useful to get together on the Friday after t= he IIW event for a OAuth breakfast chat.=0A>I am sure that there are still = a couple of topics that require brainstorming.=A0 =0A>=0A>Drop me a message= if you are able and interested.=0A>=0A>Ciao=0A>Hannes=0A>=0A>PS: Please do= not forget to read the Assertion specs so that we can get them out of the = door. =0A>(And thanks to those who have already read them.)=0A>=0A>________= _______________________________________=0A>OAuth mailing list=0A>OAuth@ietf= .org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A> ---1036955950-1230859682-1334589006=:13306 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I am planning to.

-bil= l

From: = Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: "oauth@ietf.org WG" <oauth@ietf.org>= ;
Sent: Monday, April= 16, 2012 4:55 AM
Subject:= [OAUTH-WG] IIW and OAuth

=0AHi guys,

I was wondering h= ow many of you will be at the upcoming IIW in Mountain View (or for some ot= her event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd).
=
I thought it might be good to useful to get together on the Friday afte= r the IIW event for a OAuth breakfast chat.
I am sure that there are sti= ll a couple of topics that require brainstorming. 

Drop me a m= essage if you are able and interested.

Ciao
Hannes

PS: Ple= ase do not forget to read the Assertion specs so that we can get them out o= f the door.
(And thanks to those who have already read them.)

__= _____________________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth


=20
---1036955950-1230859682-1334589006=:13306-- From phil.hunt@oracle.com Mon Apr 16 09:14:51 2012 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 846A221F8746 for ; Mon, 16 Apr 2012 09:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.178 X-Spam-Level: X-Spam-Status: No, score=-10.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LILKJXTr1muM for ; Mon, 16 Apr 2012 09:14:50 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id C9DE221F8730 for ; Mon, 16 Apr 2012 09:14:50 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3GGEle1016263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2012 16:14:48 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q3GGEkvu006330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2012 16:14:47 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3GGEkoF000543; Mon, 16 Apr 2012 11:14:46 -0500 Received: from [192.168.1.8] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Apr 2012 09:14:46 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> Date: Mon, 16 Apr 2012 09:14:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1257) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090202.4F8C4578.009B,ss=1,re=0.000,fgs=0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IIW and OAuth 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, 16 Apr 2012 16:14:51 -0000 Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote: > Hi guys,=20 >=20 > I was wondering how many of you will be at the upcoming IIW in = Mountain View (or for some other event). IIW will run from Tuesday (May = 1st) to Thursday (May 3rd).=20 >=20 > I thought it might be good to useful to get together on the Friday = after the IIW event for a OAuth breakfast chat. > I am sure that there are still a couple of topics that require = brainstorming. =20 >=20 > Drop me a message if you are able and interested. >=20 > Ciao > Hannes >=20 > PS: Please do not forget to read the Assertion specs so that we can = get them out of the door.=20 > (And thanks to those who have already read them.) >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Mon Apr 16 09:27:24 2012 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 87D0921F85D3 for ; Mon, 16 Apr 2012 09:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jtu5fYtdb2mI for ; Mon, 16 Apr 2012 09:27:24 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80D1E21F85D0 for ; Mon, 16 Apr 2012 09:27:23 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so7502618wib.13 for ; Mon, 16 Apr 2012 09:27:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=gMZTPX4FyhGK4EGfh4sgzoXRI8JMSFPCpqORSC49Dvg=; b=pJ9JsRFUHXtjU4aS6LSf/vKvn2ccmA6TD5ssZgM0r16PeM6DPZM2flRRmkhM16/O1E MLR7dLAqVrDrGWAn9GWAsld0f4wUS+scmQOXszra9jKIeyMFBM8ReWfsR0mYQslpEh26 VTiRHztrls+RP1H/0TtKUP5W2896J9zdKCjdKdXv8ZOAjqz4a7oo5rF8OSQtzs4VY9nm hPSdAB8pMIawjX4r9paHV5GhgIkJdFO/AO9KqlVeUJWIhj7PbUV4F2Y0s8FWY+pT+Gju r6iuCAG0PiWz75HJtiTlGkDg16oRmu2w/YKpJ7nDC6KTSGWkz4Z4y0HC3IgKiFbt1x8X /YRA== Received: by 10.180.85.70 with SMTP id f6mr20461630wiz.5.1334593642620; Mon, 16 Apr 2012 09:27:22 -0700 (PDT) Received: from [10.6.1.77] (nat-VI.gw1.ush2.tnib.de. [86.110.65.2]) by mx.google.com with ESMTPS id ev10sm20614537wid.10.2012.04.16.09.27.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 09:27:20 -0700 (PDT) References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> In-Reply-To: <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-53D06A22-6240-4858-B698-BB28D5BF7A10; protocol="application/pkcs7-signature" Message-Id: <6997C1ED-7419-4B0C-9AEA-CD4C62D248DB@ve7jtb.com> X-Mailer: iPad Mail (9B176) From: John Bradley Date: Mon, 16 Apr 2012 18:27:39 +0200 To: Phil Hunt X-Gm-Message-State: ALoCoQnc+nEefRqg4Nypb7PJt67pDi8RPD/1qi3MLKtQC8op9TDp55pKrxgjZnVYofED0Tj8rKso Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IIW and OAuth 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, 16 Apr 2012 16:27:24 -0000 --Apple-Mail-53D06A22-6240-4858-B698-BB28D5BF7A10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thursday morning works for me as well. John B. Sent from my iPad On 2012-04-16, at 6:14 PM, Phil Hunt wrote: > Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote: >=20 >> Hi guys,=20 >>=20 >> I was wondering how many of you will be at the upcoming IIW in Mountain V= iew (or for some other event). IIW will run from Tuesday (May 1st) to Thursd= ay (May 3rd).=20 >>=20 >> I thought it might be good to useful to get together on the Friday after t= he IIW event for a OAuth breakfast chat. >> I am sure that there are still a couple of topics that require brainstorm= ing. =20 >>=20 >> Drop me a message if you are able and interested. >>=20 >> Ciao >> Hannes >>=20 >> PS: Please do not forget to read the Assertion specs so that we can get t= hem out of the door.=20 >> (And thanks to those who have already read them.) >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-53D06A22-6240-4858-B698-BB28D5BF7A10 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTYxNjI3NDBaMCMGCSqGSIb3DQEJBDEWBBQe9bzx E5KxbBPNcXKTlmeodGa63TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQBuESmqKxeOEV+o59Lu/AHwUOGiP3Dke2XjbVFF Jvb92J2GTj3hT81t7EPDZiK/ujFJumwbULIye6k9MqZcjZbPbC1e5d2u4ruY5BybxoRLgKpWEv35 61mkYI4SqcO63Jh4UyjrYrMKVjgww3HhVT+vSMYt1I5ienK8fJgMmCQkt8h89CKZheqwcqgeS4pn oDr7SRHJVPGznVbQ68QVK/IsDp/m0k9kGSbL/OB4NRX5K5lmB58p0LEpJpKOSNmBtQ4tnSG+64G8 CjSGagCGUHc899h5PGF35dGpiIoAM0aGr78oe4ytkFRRdSoGV6FgwGiwdP41UysBuJiBo0opYAfH AAAAAAAA --Apple-Mail-53D06A22-6240-4858-B698-BB28D5BF7A10-- From jricher@mitre.org Mon Apr 16 09:42:06 2012 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 470EF11E80C1 for ; Mon, 16 Apr 2012 09:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyINGmzjn1+J for ; Mon, 16 Apr 2012 09:42:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A4C8411E80C0 for ; Mon, 16 Apr 2012 09:42:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0A5C021B0602 for ; Mon, 16 Apr 2012 12:42:00 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B461E21B0495 for ; Mon, 16 Apr 2012 12:41:59 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 16 Apr 2012 12:41:59 -0400 Message-ID: <4F8C4BB3.9050609@mitre.org> Date: Mon, 16 Apr 2012 12:41:23 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> <6997C1ED-7419-4B0C-9AEA-CD4C62D248DB@ve7jtb.com> In-Reply-To: <6997C1ED-7419-4B0C-9AEA-CD4C62D248DB@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------040809040400080505010303" X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] IIW and OAuth 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, 16 Apr 2012 16:42:06 -0000 --------------040809040400080505010303 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Thursday would conflict with IIW sessions proper, and we'd prefer a Friday morning get together. -- Justin On 04/16/2012 12:27 PM, John Bradley wrote: > Thursday morning works for me as well. > > John B. > > Sent from my iPad > > On 2012-04-16, at 6:14 PM, Phil Hunt wrote: > >> Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote: >> >>> Hi guys, >>> >>> I was wondering how many of you will be at the upcoming IIW in Mountain View (or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd). >>> >>> I thought it might be good to useful to get together on the Friday after the IIW event for a OAuth breakfast chat. >>> I am sure that there are still a couple of topics that require brainstorming. >>> >>> Drop me a message if you are able and interested. >>> >>> Ciao >>> Hannes >>> >>> PS: Please do not forget to read the Assertion specs so that we can get them out of the door. >>> (And thanks to those who have already read them.) >>> >>> _______________________________________________ >>> 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 --------------040809040400080505010303 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Thursday would conflict with IIW sessions proper, and we'd prefer a Friday morning get together.

 -- Justin

On 04/16/2012 12:27 PM, John Bradley wrote: 
Thursday morning works for me as well.

John B.

Sent from my iPad

On 2012-04-16, at 6:14 PM, Phil Hunt <phil.hunt@oracle.com> wrote:


Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote:


Hi guys, 

I was wondering how many of you will be at the upcoming IIW in Mountain View (or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd). 

I thought it might be good to useful to get together on the Friday after the IIW event for a OAuth breakfast chat.
I am sure that there are still a couple of topics that require brainstorming.  

Drop me a message if you are able and interested.

Ciao
Hannes

PS: Please do not forget to read the Assertion specs so that we can get them out of the door. 
(And thanks to those who have already read them.)

_______________________________________________
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

--------------040809040400080505010303-- From dick.hardt@gmail.com Mon Apr 16 09:44:01 2012 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 318E411E80AC for ; Mon, 16 Apr 2012 09:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca0janLcqKaV for ; Mon, 16 Apr 2012 09:44:00 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B75811E80AB for ; Mon, 16 Apr 2012 09:43:59 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3715501wgb.13 for ; Mon, 16 Apr 2012 09:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=fEGEkimuV6m9BYtcmkeYauMOX9MKIb5Nnn6QZrlemFs=; b=u8sGXjxoENAwa/1jjBJCB7O/Wi9vhivtDqdGbrGwRjq9bD1zeR8VY9G/f2zmfPsdSn EPFfFgNUCvCzCGKaPRwA5yUZRxvR6FDTTs4bFv+fsngq40rAWspet01/ZdYLsMy/xQQp HIIGEmDqt4ACIPpPyzr2DsrwiVCRz8OCEkubYF8m9FrRw3Yp/Kld3A4sRSYVAHePgHai ivesDjXuof4JitIs33tnuS94wKxo8N2yf6LEqcXc748K8/4EQI5Mnyxx1SDvvK09Qx7H LW5TYO4g4sQTKZdrWb5YT83POABgIJg47s/jmyYSFhL2zDDGpQcTgZMPsFamBlZ/wyiH dmXQ== Received: by 10.216.135.20 with SMTP id t20mr6656731wei.99.1334594639161; Mon, 16 Apr 2012 09:43:59 -0700 (PDT) References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> <6997C1ED-7419-4B0C-9AEA-CD4C62D248DB@ve7jtb.com> <4F8C4BB3.9050609@mitre.org> From: Dick Hardt In-Reply-To: <4F8C4BB3.9050609@mitre.org> Mime-Version: 1.0 (1.0) Date: Mon, 16 Apr 2012 09:56:38 -0700 Message-ID: <-677124445697915960@unknownmsgid> To: Justin Richer Content-Type: multipart/alternative; boundary=0016e6de179c62e99204bdce879c Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] IIW and OAuth 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, 16 Apr 2012 16:44:01 -0000 --0016e6de179c62e99204bdce879c Content-Type: text/plain; charset=ISO-8859-1 I'd also prefer something during IIW schedule (tues - thu) -- Dick On 2012-04-16, at 9:42 AM, Justin Richer wrote: Thursday would conflict with IIW sessions proper, and we'd prefer a Friday morning get together. -- Justin On 04/16/2012 12:27 PM, John Bradley wrote: Thursday morning works for me as well. John B. Sent from my iPad On 2012-04-16, at 6:14 PM, Phil Hunt wrote: Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve. Phil @independentidwww.independentid.comphil.hunt@oracle.com On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote: Hi guys, I was wondering how many of you will be at the upcoming IIW in Mountain View (or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd). I thought it might be good to useful to get together on the Friday after the IIW event for a OAuth breakfast chat. I am sure that there are still a couple of topics that require brainstorming. Drop me a message if you are able and interested. Ciao Hannes PS: Please do not forget to read the Assertion specs so that we can get them out of the door. (And thanks to those who have already read them.) _______________________________________________ OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0016e6de179c62e99204bdce879c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'd also prefer somet= hing during IIW schedule (tues - thu)

-- Dick

On 2012-= 04-16, at 9:42 AM, Justin Richer <j= richer@mitre.org> wrote:

=20 =20 =20 Thursday would conflict with IIW sessions proper, and we'd prefer a Friday morning get together.

=A0-- Justin

On 04/16/2012 12:27 PM, John Bradley wrote: 
Thursday morning works for me as well.

John B.

Sent from my iPad

On 2012-04-16, at 6:14 PM, Phil Hunt <phil.hunt@oracle.com> wrote:


Can do, but would prefer a date Tues-Thurs as am flying home T=
hurs eve.

Phil

@independentid
www.independentid.com
=
phil.hunt@oracle.com





On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote:


Hi guys,=20

I was wondering how many of you will be at the upcoming IIW in Mountain Vie=
w (or for some other event). IIW will run from Tuesday (May 1st) to Thursda=
y (May 3rd).=20

I thought it might be good to useful to get together on the Friday after th=
e IIW event for a OAuth breakfast chat.
I am sure that there are still a couple of topics that require brainstormin=
g. =20

Drop me a message if you are able and interested.

Ciao
Hannes

PS: Please do not forget to read the Assertion specs so that we can get the=
m out of the door.=20
(And thanks to those who have already read them.)

_______________________________________________
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

=20
___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth
--0016e6de179c62e99204bdce879c-- From Axel.Nennker@telekom.de Mon Apr 16 10:54:47 2012 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 734E521F877E for ; Mon, 16 Apr 2012 10:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu1BOE4dL92Z for ; Mon, 16 Apr 2012 10:54:46 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1DD21F8771 for ; Mon, 16 Apr 2012 10:54:46 -0700 (PDT) Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 16 Apr 2012 19:54:44 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.250]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Mon, 16 Apr 2012 19:54:44 +0200 From: To: , Date: Mon, 16 Apr 2012 19:54:42 +0200 Thread-Topic: [OAUTH-WG] IIW and OAuth Thread-Index: Ac0b7BaTe5R8ZXV6Slaq+gP2Df0M0AADc72A Message-ID: References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> In-Reply-To: <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] IIW and OAuth 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, 16 Apr 2012 17:54:47 -0000 Same for me. Tues-Thurs works better for me too. Axel -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Monday, April 16, 2012 6:15 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] IIW and OAuth Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote: > Hi guys,=20 >=20 > I was wondering how many of you will be at the upcoming IIW in Mountain V= iew (or for some other event). IIW will run from Tuesday (May 1st) to Thurs= day (May 3rd).=20 >=20 > I thought it might be good to useful to get together on the Friday after = the IIW event for a OAuth breakfast chat. > I am sure that there are still a couple of topics that require brainstorm= ing. =20 >=20 > Drop me a message if you are able and interested. >=20 > Ciao > Hannes >=20 > PS: Please do not forget to read the Assertion specs so that we can get t= hem out of the door.=20 > (And thanks to those who have already read them.) >=20 > _______________________________________________ > 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 From derek@ihtfp.com Mon Apr 16 11:51:00 2012 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 9C97211E809D for ; Mon, 16 Apr 2012 11:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsrBBau7kXvo for ; Mon, 16 Apr 2012 11:51:00 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id BF19611E809A for ; Mon, 16 Apr 2012 11:50:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DA5982602A5; Mon, 16 Apr 2012 14:50:58 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16359-10; Mon, 16 Apr 2012 14:50:58 -0400 (EDT) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 03A0C2600BB; Mon, 16 Apr 2012 14:50:58 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3GIosMC012295; Mon, 16 Apr 2012 14:50:54 -0400 From: Derek Atkins To: Justin Richer References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F88713C.6070309@mitre.org> Date: Mon, 16 Apr 2012 14:50:51 -0400 In-Reply-To: <4F88713C.6070309@mitre.org> (Justin Richer's message of "Fri, 13 Apr 2012 14:32:28 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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, 16 Apr 2012 18:51:00 -0000 Justin Richer writes: > OK, but with SWD and discovery off the table, can this now be > considered to be within that manageable number instead? We wanted to keep the # of WG items to approximately 5. Once we finish some of these items and get them off our plate we could roll new items onto the plate, theoretically. > -- Justin -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From jricher@mitre.org Mon Apr 16 12:05:13 2012 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 BD3D511E80DE for ; Mon, 16 Apr 2012 12:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izGNk8iM3JwL for ; Mon, 16 Apr 2012 12:05:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2B511E80D2 for ; Mon, 16 Apr 2012 12:05:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2382A21B0499; Mon, 16 Apr 2012 15:05:11 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 114AB21B043A; Mon, 16 Apr 2012 15:05:11 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 16 Apr 2012 15:05:10 -0400 Message-ID: <4F8C6D43.2030701@mitre.org> Date: Mon, 16 Apr 2012 15:04:35 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Derek Atkins References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F88713C.6070309@mitre.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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, 16 Apr 2012 19:05:14 -0000 >> OK, but with SWD and discovery off the table, can this now be >> considered to be within that manageable number instead? > We wanted to keep the # of WG items to approximately 5. Once we finish > some of these items and get them off our plate we could roll new items > onto the plate, theoretically. > That's definitely true going forward, but what I was saying is that the number of items under consideration is now down to 4, with SWD moving to the Apps group. I was proposing that the whole introspection endpoint and general AS-PR connection could be this group's fifth starting document. -- Justin From derek@ihtfp.com Mon Apr 16 12:07:14 2012 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 BD9DE21F85D8; Mon, 16 Apr 2012 12:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.936 X-Spam-Level: X-Spam-Status: No, score=-101.936 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ME3Af3heGFZ; Mon, 16 Apr 2012 12:07:14 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6E021F85CE; Mon, 16 Apr 2012 12:07:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6FBA52602A6; Mon, 16 Apr 2012 15:07:13 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16559-07; Mon, 16 Apr 2012 15:07:12 -0400 (EDT) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 5BCC92602A5; Mon, 16 Apr 2012 15:07:12 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3GJ79Ha012606; Mon, 16 Apr 2012 15:07:09 -0400 From: Derek Atkins To: "Murray S. Kucherawy" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> Date: Mon, 16 Apr 2012 15:07:08 -0400 In-Reply-To: <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> (Murray S. Kucherawy's message of "Fri, 13 Apr 2012 17:45:32 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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, 16 Apr 2012 19:07:14 -0000 "Murray S. Kucherawy" writes: > Thank you Stephen, I think. :-) > > So the discussion on apps-discuss now should be focused on which of the two should be the basis for forward progress. I've placed both documents in "Call for Adoption" state in the datatracker for appsawg. >From an OAUTH perspective I believe that we should help define the requirements of what this protocol needs to provide (be it webfinger, swd, or yadp (Yet Another Discovery Protocol) -- whatever it's named!) I think there are two main differerences between webfinger and swd: a) whole-document vs. individual attributes b) a perceived authorization model to control access to said attributes In particular I feel there are some specific security requirements that must be bet by the protocol, but I think it's easily accomplished by a small amount of text that effectively says: 1) requestors of the service should authenticate (or be treated as an anonymous user) 2) content returned must be dynamic and dependent on the authorization of the authenticated user. This leaves only the perceived issue of "whole document" vs "individual attribute". If a client ever wants more than one attribute then a whole document approach reduces the number of round trips. However if documents get large that could also affect performance. We might, then, need a way to specify which attributes are requested, but allow for a wildcard to return "everything I am authorized to see". > Let the games begin. Heh. Play ball! > -MSK > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From derek@ihtfp.com Mon Apr 16 12:16:55 2012 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 6B6AE11E80DE for ; Mon, 16 Apr 2012 12:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt2-0fdGbKAi for ; Mon, 16 Apr 2012 12:16:55 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id D778C11E80D3 for ; Mon, 16 Apr 2012 12:16:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 1B7A92602A6; Mon, 16 Apr 2012 15:16:42 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16667-02; Mon, 16 Apr 2012 15:16:40 -0400 (EDT) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id D1107260299; Mon, 16 Apr 2012 15:16:40 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3GJGcJ4012769; Mon, 16 Apr 2012 15:16:38 -0400 From: Derek Atkins To: Eran Hammer References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F47@P3PWEX2MB008.ex2.secureserver.net> <6760C38E-7C0C-412F-A285-8F4CB2858F30@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE92E4@P3PWEX2MB008.ex2.secureserver.net> Date: Mon, 16 Apr 2012 15:16:37 -0400 In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE92E4@P3PWEX2MB008.ex2.secureserver.net> (Eran Hammer's message of "Sun, 15 Apr 2012 20:36:01 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration 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, 16 Apr 2012 19:16:55 -0000 Eran Hammer writes: > All I was saying is that it would be better to postpone it until the > discovery layer, which this draft clearly relies upon, is a bit > clearer. I would be satisfied with a simple note stating that if the > discovery work at the APP area isn't complete, the WG may choose to > delay work on this document until ready. I don't feel that this is explicitly required, but I have no objection to making it clearer in the charter that the DCR is dependent on Discovery. Hannes? > EH -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From kevinmarks@gmail.com Mon Apr 16 12:47:50 2012 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 EAFB321F861F; Mon, 16 Apr 2012 12:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3ImB1JM5IEM; Mon, 16 Apr 2012 12:47:49 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC19421F8627; Mon, 16 Apr 2012 12:47:48 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4096639qcs.31 for ; Mon, 16 Apr 2012 12:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rN4iHozaL+sQF+E4gUhYVhiVdjQMcRDgA+jL5dYO65w=; b=R5O2eEV/zIXkybjzT+4rrcbne15WUDXuOATeR0MCsvBz4W0ouFXWs61ZUCBh0B1hXw g30nolXyjp/Y0Po0JUKHmt2wkAnfoY9BZ5VZGZ6tEghC2S9jTwUN0lyPDyZMnvUHO0nB nhTjtHntbpnyzga0Jj6NyrvUaKLEL20yuUBexNBwkRO5z6PBDLKRoIguEKk3X76hoCEm KKxekxtx0arPgEKZPAxrR+Sk85LEJ4/ZNarZ4sD+Cb3eGWpbHoFtERVyXMPDeZJrQFti VzK9OJmXNWIdFQRl4qaOErjM2/ArSAQEukvquAy0R+qQ+W+lgbbzr5fzeIfTA1LT7gYD 29XQ== MIME-Version: 1.0 Received: by 10.229.136.131 with SMTP id r3mr5203372qct.129.1334605668374; Mon, 16 Apr 2012 12:47:48 -0700 (PDT) Received: by 10.229.38.70 with HTTP; Mon, 16 Apr 2012 12:47:48 -0700 (PDT) In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> Date: Mon, 16 Apr 2012 12:47:48 -0700 Message-ID: From: Kevin Marks To: Derek Atkins Content-Type: multipart/alternative; boundary=00248c768f9ec75a1104bdd118ce Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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, 16 Apr 2012 19:47:50 -0000 --00248c768f9ec75a1104bdd118ce Content-Type: text/plain; charset=UTF-8 On Mon, Apr 16, 2012 at 12:07 PM, Derek Atkins wrote: > > I think there are two main differerences between webfinger and swd: > > a) whole-document vs. individual attributes > b) a perceived authorization model to control access to said attributes > > In particular I feel there are some specific security requirements that > must be bet by the protocol, but I think it's easily accomplished by > a small amount of text that effectively says: > > 1) requestors of the service should authenticate (or be treated as an > anonymous user) > 2) content returned must be dynamic and dependent on the authorization > of the authenticated user. > I think requesters MAY authenticate, not SHOULD. > > This leaves only the perceived issue of "whole document" vs "individual > attribute". If a client ever wants more than one attribute then a whole > document approach reduces the number of round trips. However if > documents get large that could also affect performance. We might, then, > need a way to specify which attributes are requested, but allow for a > wildcard to return "everything I am authorized to see". > Something like the PoCo query model? --00248c768f9ec75a1104bdd118ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 16, 2012 at 12:07 PM, Derek Atki= ns <derek@ihtfp.com= > wrote:
I think there are two main differerences between webfinger and swd:

a) whole-document vs. individual attributes
b) a perceived authorization model to control access to said attributes

In particular I feel there are some specific security requirements that
must be bet by the protocol, but I think it's easily accomplished by a small amount of text that effectively says:

1) requestors of the service should authenticate (or be treated as an
=C2=A0 anonymous user)
2) content returned must be dynamic and dependent on the authorization
=C2=A0 of the authenticated user.

I think r= equesters MAY authenticate, not SHOULD.=C2=A0
=C2=A0

This leaves only the perceived issue of "whole document" vs "= ;individual
attribute". =C2=A0If a client ever wants more than one attribute then = a whole
document approach reduces the number of round trips. =C2=A0However if
documents get large that could also affect performance. =C2=A0We might, the= n,
need a way to specify which attributes are requested, but allow for a
wildcard to return "everything I am authorized to see".

Something like the PoCo query model?=C2=A0
=
--00248c768f9ec75a1104bdd118ce-- From Michael.Jones@microsoft.com Mon Apr 16 15:21:39 2012 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 9781011E808A for ; Mon, 16 Apr 2012 15:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti-6XpYBtG56 for ; Mon, 16 Apr 2012 15:21:37 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7515E11E80E6 for ; Mon, 16 Apr 2012 15:21:35 -0700 (PDT) Received: from mail34-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Mon, 16 Apr 2012 22:21:33 +0000 Received: from mail34-ch1 (localhost [127.0.0.1]) by mail34-ch1-R.bigfish.com (Postfix) with ESMTP id 966C01C026C; Mon, 16 Apr 2012 22:21:33 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zz9371I936eK542M1432N98dK1506Jzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail34-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail34-ch1 (localhost.localdomain [127.0.0.1]) by mail34-ch1 (MessageSwitch) id 1334614891383395_13127; Mon, 16 Apr 2012 22:21:31 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail34-ch1.bigfish.com (Postfix) with ESMTP id 4DA272E0061; Mon, 16 Apr 2012 22:21:31 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 16 Apr 2012 22:21:30 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0283.004; Mon, 16 Apr 2012 22:21:28 +0000 From: Mike Jones To: "Axel.Nennker@telekom.de" , "phil.hunt@oracle.com" , "hannes.tschofenig@gmx.net" Thread-Topic: [OAUTH-WG] IIW and OAuth Thread-Index: AQHNG8fgbU5eQkiur0+viVoW67ENh5adoIqAgAAb5gCAAEpg0A== Date: Mon, 16 Apr 2012 22:21:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366487923@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] IIW and OAuth 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, 16 Apr 2012 22:21:39 -0000 I propose that you schedule this session at IIW on Thursday, as that looks = like the time that will garner the greatest participation. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= xel.Nennker@telekom.de Sent: Monday, April 16, 2012 10:55 AM To: phil.hunt@oracle.com; hannes.tschofenig@gmx.net Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] IIW and OAuth Same for me. Tues-Thurs works better for me too. Axel -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Monday, April 16, 2012 6:15 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] IIW and OAuth Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote: > Hi guys,=20 >=20 > I was wondering how many of you will be at the upcoming IIW in Mountain V= iew (or for some other event). IIW will run from Tuesday (May 1st) to Thurs= day (May 3rd).=20 >=20 > I thought it might be good to useful to get together on the Friday after = the IIW event for a OAuth breakfast chat. > I am sure that there are still a couple of topics that require brainstorm= ing. =20 >=20 > Drop me a message if you are able and interested. >=20 > Ciao > Hannes >=20 > PS: Please do not forget to read the Assertion specs so that we can get t= hem out of the door.=20 > (And thanks to those who have already read them.) >=20 > _______________________________________________ > 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 From ve7jtb@ve7jtb.com Mon Apr 16 15:28:26 2012 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 BD53921F852D for ; Mon, 16 Apr 2012 15:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofPSjbQq-XqB for ; Mon, 16 Apr 2012 15:28:26 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 670D721F85A4 for ; Mon, 16 Apr 2012 15:28:08 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3918177wgb.13 for ; Mon, 16 Apr 2012 15:28:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MQ3TFNoMLNqD3tPgL/g4wVCAIrnvwHiSgaksFLNalxw=; b=LD5Qd/sgZPVWO2wUYRcROiiN9Q7X8527vZ6r0z3hZCddTZkjApT/QEwMu7T5JhuFNm M0H7frNhsU8pG6MyNEvgH5qV9c33QuOD0SIDc/uZIadBFt68c+TB37kCOd4M/ojyJnjn 81uChP806QXhHgOI+m2YGgQG0riCd5mLVee5yNWNmPvzh0Xd11ByVIBkl23qzo3gHdPq YOXCTIYs4y5bNphM0xAyOXnk/qbmXpGDQId962RCR0btWN+CxK3ZHzHDKTzJZNwMCi1l wvwj3VXZQTNrIaE1Zexrr2X5LnIUvKdHUP1KR1wT89fXMrNKP1k2T3S76Gl0NGKwgl4N EIZg== Received: by 10.180.24.66 with SMTP id s2mr22772167wif.7.1334615287509; Mon, 16 Apr 2012 15:28:07 -0700 (PDT) Received: from [10.0.9.253] ([212.144.56.68]) by mx.google.com with ESMTPS id k6sm22591255wie.9.2012.04.16.15.28.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 15:28:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366487923@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 17 Apr 2012 00:28:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34E26D40-340F-48A9-9761-D0B2B558DB6A@ve7jtb.com> References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> <4E1F6AAD24975D4BA5B168042967394366487923@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnW7bA3N0v+kX7+GE0iQlXWyNx0jn8iEbFb4+WzbhD0AGSxGsY0QsiGwi702s8+cdUdBd2r Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] IIW and OAuth 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, 16 Apr 2012 22:28:26 -0000 I only purchased the Tuesday for IIW because I am tied up Wednesday and = Thursday is traditionally digital death or something like that. =20 Tuesday is best if it is going to be during IIW hours. Though I thought = Hannes was suggesting something outside IIW. John B. On 2012-04-17, at 12:21 AM, Mike Jones wrote: > I propose that you schedule this session at IIW on Thursday, as that = looks like the time that will garner the greatest participation. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Axel.Nennker@telekom.de > Sent: Monday, April 16, 2012 10:55 AM > To: phil.hunt@oracle.com; hannes.tschofenig@gmx.net > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] IIW and OAuth >=20 > Same for me. Tues-Thurs works better for me too. > Axel >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Monday, April 16, 2012 6:15 PM > To: Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] IIW and OAuth >=20 > Can do, but would prefer a date Tues-Thurs as am flying home Thurs = eve. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote: >=20 >> Hi guys,=20 >>=20 >> I was wondering how many of you will be at the upcoming IIW in = Mountain View (or for some other event). IIW will run from Tuesday (May = 1st) to Thursday (May 3rd).=20 >>=20 >> I thought it might be good to useful to get together on the Friday = after the IIW event for a OAuth breakfast chat. >> I am sure that there are still a couple of topics that require = brainstorming. =20 >>=20 >> Drop me a message if you are able and interested. >>=20 >> Ciao >> Hannes >>=20 >> PS: Please do not forget to read the Assertion specs so that we can = get them out of the door.=20 >> (And thanks to those who have already read them.) >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > 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 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From allan.foster@forgerock.com Tue Apr 17 01:52:30 2012 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 6D50721F8581 for ; Tue, 17 Apr 2012 01:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyZJHZudF4Tf for ; Tue, 17 Apr 2012 01:52:25 -0700 (PDT) Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) by ietfa.amsl.com (Postfix) with SMTP id A8D6921F860D for ; Tue, 17 Apr 2012 01:52:20 -0700 (PDT) Received: from mail-bk0-f47.google.com ([209.85.214.47]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKT40vQA045J0f/1++ai3U9zRRdb/cdqkQ@postini.com; Tue, 17 Apr 2012 08:52:21 UTC Received: by bkcjg15 with SMTP id jg15so4871437bkc.6 for ; Tue, 17 Apr 2012 01:52:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-gm-message-state; bh=2ljJmuc6EptbaavaBjRD2wf/xPQ/QuXLykWH+qof548=; b=UqEpXY2U+HgvYqupH6QDUuuZEbe2LcWFah3X2VGSTJrost+L9hvUsCnj7SSZbA5oUv 7b5/v+REpmOfvOJ+0weDbJHoWwxn1ChRf2A4XBGMMQwo19toWArSzc7+f4zRP4DOWkDx A25qIEvYl/Ublm8SdIZC/H1qGRQJaYuk+5p/Klj12/jD0V0xY0E24yLelqUqEaH0NSvz Th9liu7hdl/k1PcPMCPI1Cs+taJtAcM6ojtNaJ/9yedqBPSF5aRkhAUaei+NINnmZDWY CDWXrJ31wgSt+rVP51qtqTl09iwdW13Povv1wZAA/s9rVXPYJzFriKWdte3k1O1CrGXv buBw== Received: by 10.205.122.73 with SMTP id gf9mr4496885bkc.96.1334652735783; Tue, 17 Apr 2012 01:52:15 -0700 (PDT) Received: from MacGuruMacBook.local (macguru.com. [76.9.241.41]) by mx.google.com with ESMTPS id f11sm36317985bkw.6.2012.04.17.01.52.10 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 01:52:14 -0700 (PDT) Message-ID: <4F8D2F34.5000009@forgerock.com> Date: Tue, 17 Apr 2012 01:52:04 -0700 From: Allan Foster Organization: Forgerock AS User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120410 Thunderbird/12.0 MIME-Version: 1.0 To: oauth@ietf.org References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> <4E1F6AAD24975D4BA5B168042967394366487923@TK5EX14MBXC284.redmond.corp.microsoft.com> <34E26D40-340F-48A9-9761-D0B2B558DB6A@ve7jtb.com> In-Reply-To: <34E26D40-340F-48A9-9761-D0B2B558DB6A@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------050501010101090102070900" X-Gm-Message-State: ALoCoQk6CVOh6EMAAw/7iCRVlXb99tAdFFHfnymEiMENlf5HeIRMZnjZEJiv3Srg8ETNYjgwi10Y Subject: Re: [OAUTH-WG] IIW and OAuth 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: Tue, 17 Apr 2012 08:52:30 -0000 This is a multi-part message in MIME format. --------------050501010101090102070900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am also only at IIW on tuesday. Allan On 4/16/12 15:28, John Bradley wrote: > I only purchased the Tuesday for IIW because I am tied up Wednesday and Thursday is traditionally digital death or something like that. > > Tuesday is best if it is going to be during IIW hours. Though I thought Hannes was suggesting something outside IIW. > > John B. > On 2012-04-17, at 12:21 AM, Mike Jones wrote: > >> I propose that you schedule this session at IIW on Thursday, as that looks like the time that will garner the greatest participation. >> >> -- Mike >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Axel.Nennker@telekom.de >> Sent: Monday, April 16, 2012 10:55 AM >> To: phil.hunt@oracle.com; hannes.tschofenig@gmx.net >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] IIW and OAuth >> >> Same for me. Tues-Thurs works better for me too. >> Axel >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >> Sent: Monday, April 16, 2012 6:15 PM >> To: Hannes Tschofenig >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] IIW and OAuth >> >> Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote: >> >>> Hi guys, >>> >>> I was wondering how many of you will be at the upcoming IIW in Mountain View (or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd). >>> >>> I thought it might be good to useful to get together on the Friday after the IIW event for a OAuth breakfast chat. >>> I am sure that there are still a couple of topics that require brainstorming. >>> >>> Drop me a message if you are able and interested. >>> >>> Ciao >>> Hannes >>> >>> PS: Please do not forget to read the Assertion specs so that we can get them out of the door. >>> (And thanks to those who have already read them.) >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 -- ForgeRock *Allan Foster* VP Community & OpenAM Eng e: allan.foster@forgerock.com t: +1.503.334.2546 w: www.forgerock.com ForgeRock -- a First class Citizen in the Open Source Community --------------050501010101090102070900 Content-Type: multipart/related; boundary="------------020802020209010907080704" --------------020802020209010907080704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am also only at IIW on tuesday.

Allan

On 4/16/12 15:28, John Bradley wrote: 
I only purchased the Tuesday for IIW because I am tied up Wednesday and Thursday is traditionally digital death or something like that.    

Tuesday is best if it is going to be during IIW hours.  Though I thought Hannes was suggesting something outside IIW.

John B.
On 2012-04-17, at 12:21 AM, Mike Jones wrote:


I propose that you schedule this session at IIW on Thursday, as that looks like the time that will garner the greatest participation.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Axel.Nennker@telekom.de
Sent: Monday, April 16, 2012 10:55 AM
To: phil.hunt@oracle.com; hannes.tschofenig@gmx.net
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] IIW and OAuth

Same for me. Tues-Thurs works better for me too.
Axel

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, April 16, 2012 6:15 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] IIW and OAuth

Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote:


Hi guys, 

I was wondering how many of you will be at the upcoming IIW in Mountain View (or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd). 

I thought it might be good to useful to get together on the Friday after the IIW event for a OAuth breakfast chat.
I am sure that there are still a couple of topics that require brainstorming.  

Drop me a message if you are able and interested.

Ciao
Hannes

PS: Please do not forget to read the Assertion specs so that we can get them out of the door. 
(And thanks to those who have already read them.)

_______________________________________________
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


_______________________________________________
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

--
ForgeRock Allan Foster VP Community & OpenAM Eng
e: allan.foster@forgerock.com
t: +1.503.334.2546
w: www.forgerock.com

ForgeRock -- a First class Citizen in the Open Source Community
--------------020802020209010907080704 Content-Type: image/png; name="forgerock_logo.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="forgerock_logo.png" iVBORw0KGgoAAAANSUhEUgAAAOIAAAA8CAYAAAB7JGaIAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAG29JREFUeNrsXQd8HOWVf7NV2pVWXbIsW5axMc1cKAZCAjFw CeHoSUiOlgslEBICpoRyR4ALBEK5XzguhBD4kUACARL6FTiSHFxCQjuKAdNtuUhW79rV9rn3 Zt5Is99+Mzu7WoFtzTMP7U6fb7//9/6vzDdK9JoOcKU8oqYA7vYcDS/1KFARrHAbxIFk0imI 1NRApL4RGxAXKGX9RUyfFe27wifANTX4aX8V1FX4dQXqEtSFqLWoHtwggdsMqKraBaq6CT+/ qyjKWlz3ukdRYvphFNM5FMhkMrDn8qWwpK0F0vi5GPG5XcGVeSbtCJ3TEUBn4d82cWU2qwPL 7/XhYOpb5Pf59vZ6vRrkMrgOAbYhmUz9OpFO34vA6/R4PKCUYfBwgejKfJFlqOchzL6JIAzn WeZMFtDSQU1VGBa3NEFjXQ0EAj7wISAVk33NZjM7pdLZq6cSict6+oce7h0cvjWWSLyK1lJD cKmgdIHoyo4uQdQfIIwuxL+BXLqqo4uWNNXVQvuCJmhurAOvx4uAy+JylYCXR3D9fi8EA1UV dZHqU5e1LzylZ2DoL1sHhu4eGpt4HK3maCn82gWiKzuwKAhC9RH8cJTUg1R1C7b70nboaGvV LSMCL51J23uduGNG1X1ApK4K7nvQkoULDuofGrkhEPCfjyD+rQtEV7YvqCASVLQ+HurfZQ3U gA8t2j1WICRE0elWLlsK7QubIZVOl3SSrJqFLNJakpaGupasqv4Klw0poPyxmON43K7gyieL RIBUKiUSxnLI9agnWq3MIPjRiiEIWyBtAiFZSQrYGKqq+WpeZ5Y0WlMEIVHhn+B9RTSkO1TX IrryCVtEj2aNFPLHppMLs5ZPI0zWWFoxBFFVKATL2xdqKQeVl3k8CgT8fvQBfUQ5gaKlHq9H s9o6SFXNehOI0+mMBuBUKj1NZZWZSM1uuPGFum/qUlNXthMgplMJLTiieH26SZqlIFx+qAdm LNbjOTqQjhLokmiNvQi2SHUYqsIhQB8PKCWRmyOUmHEwrGMW4okkRCejMBWPaykOAjTu+S3c 6nbcdsDr8bhAdGXbF+rQqUQc/JVhm87vWP4O9W/toi1BBFtjbY12pppINVRXEQCDOriYdurX Ya4wUHNAOO3b4UASDlVqSoCcJEBOTaGVz7QiwA/DTR4amZjUjusC0ZVtWrxoCScnJ6BOA6Iy WzCeareSaGV1MAQLmhuhqioMPqSgKgVcsoUqYRQTOHNwzSBTNIBXNNRrVDuOYOzpGzzkzQ/W PzQ6ES2YYHSDNa588vQUfbFYNAYeBITuZ5WsNfi/1XbWkI6/tG0BNDbUaZRUyxeqIBwHhM8g LJOpEejJgg+paH1dLVrZwNkDw2PP4eJdzTZWpi4QXfnkgYj/spkMUrrYbA+1E0jK1gyQUIdf 3tYKbS1NkM4YAJTBQhFtnkBPVWFdrtI/8j3bWps8NdVVqxGcTyiqugQVrNQFoivbBj31+2F4 cJBMCltFtRQNWR2fLNWipgYEYYMG+lyfT2b9rOipMwtJIA9VVsLi1iaiwysQnHeqYP3PBaIr 24ZV1KKnSYjHJrWOWSqe5SBUoRb9wQ6kpBlOvucHYcDCCioSCylaQ/n+lOxfuqgVKGqKwDwc F37Z9RFd2Q6sYgBGhoc1qlbi81BeGSWlYu4lrc3aX4rQzuT7RFApBYIzqoV1VKUATqezsKC5 CWqrw5pFRlnjAtGV7cIqppIJSJKvWFpm35cPRBVqqkJQG6kywGBDLdUCARtF8lfcF0zBGxUq ggFoX9CM1lED6OdYXSC6su1bxaHBAfCUZhWl6Th6ssJjSh8o0lSCKqGmMksHNuvEvKOqpUt2 Xb4UasIh41nHL7lAdGU7sYrkK0ZnTU0JyxVa8j6iVbyYTlIgGCOzhE6sZP5xqSC8Hs+/GK0i 16Z+xgWiK9uHVfT5dV/RNLVFKRaROn6oIqjVjRqlc7l2VrWxdlYpCjvfUpbwV7V61ebGemPR zqgtLhBd2fatoscLyURc8xWzxdWe+kSy6fN4ZWbXgTVUJD6h1baqjeXUUxn0xL/f56VN63DZ HuJ5XCC6su36igMD2ixO+oOKjtTvBHNyG2vlD4pglNWcKrbHoCBRpLoKqkMhzWcESfWPC0RX tllfkTptT9cWqruxoIl56nMCOgrWzADUKkmvSoI4ik2wRrUAqsopE4D21matrA6/Hy5euwtE V7ZZ8Xh92vOCPV2bNTA6YKn56QuJScwHoQg+kIBRtaCuigUtzU2F0LU3RKqhJhwmINIUjnu5 FnEORVVVtxHKDka0jFs26zTVPniT5xDSY0qKLTktVFkDFoEc1WaffGtKzziSVocqqY/QgPFl cQRZxDcw2x5Ed5dE7ZnPHUfLFam2HaWmxENT206hZrZnXIE+q5oocbv+p4MxjWDcBK3tHWCT YvQJoyICsVCsRpEASuYPWvmVSuFjqIpOh/FiKoMBI495FC652jgJXfgLqM2oqVk2Mk1t/Rbq Adxp5qXsWjkMrypNlqtRn+N2zxZjaBmEw6gfoj6DSjOFjW5nzUN942HUBN+Tl+/rSNTOQpYx nU5B/9YuaF64SEtsSLDrk6JOkQyWthbRKpADFv6i/XJKYRjgD/p9BhD3weXUHi8aF04V6wGw mVqgCAlBmSdN364CDNiaB6dehFcajoX3h+Kyafep49XPwiUg9vI3qF9BvQL1bNT/3o6aqBL0 ae3NQqD0O9mZ8ouJRFK3jIuXyMDoLxSsoe8018yMB6EUIHlQwnolLziUTCa1SbLoQWSq8snq AZyTDSC6PmJZkYj/IXE8PvQ2VAa8WvX9HEo76hNsTeaNEBjT2KFHBvpkwRNvvkFU8ixkAvfP rTu1isLarStUDDCzjuawiUZjmq+rxxCm9zkR6ekSKloQTXkv6vd4lCoWpNQII2WguNs3FnFM XpbYAPs17gx/6g5ARcWcvoyG/K27UA8qRO12KDD6gzAxPgE1dQ3IQvzmju2z9wc5kJFMQQIt FBVkq9MOZyF/0HwEq6cw8ukynZ9mfBse1icAJ0to2qIJP9NEV18XL3zCxOFdKRWMOISt9qyD V4KrIKNmtchdAXmdrVtA4pz42Ic/GHW5ZF+iehejfnc+tbHH64WRoQFoaG7lFIUq9xElNJFS ImSh6MHdjDYVomoDMqun9RVJcCYf1DQlY19fH0wlEuDDz6QGNeV9T8DtrvFJrlpxoTRLwVZd nOyCVY0r4c/dfidW8WUoPAcmDf0/tgAczWZ9Oeqkg6vzm4JFSQBQt08g0oRTk1DXkEKrGDCz MluLqO2LC0dGRqG2NsIP7RZK3jsN4OQCntIVA4PDMDQ8AsaUil6PwvWz0/tT51j1cc3iRkWu VHW+J2oHn5xI/vvsrFK01SosT+H+Ju44dPVdJvq7GPUQ/ksRxXs5CmemKhSp3AW1AfQw+RbU tby90eJmS5QC+4gm+WZ7g/4+vWo+H9HCN8z0kIzgFzyvwRuVn4EEjsAej7cUrx+E6yKw4ggK C4R1rWwZP7AIkHwW9QjU/bktA9zexIDeBT0K+3twnnqKoB7Ix13JbUvH24r6NupLqK84HBgK Bf+WSxBA0711YZt2jQ4PQV1zK1jN/qZIbAuBhKY+HEKQtLa2aNRRDjIxlSGzgvnfyQqSP9jb OwADQ8M5R9AmLfZ4jFI3Y83KuQYiddYrUb/KP55MstyJb0T9naQ1KTJ4E9PlFHcm6jw/Qj2P fxSDVj/JwKBefxLqBQwakRsOoj6K+n3UKtT/ZEtBnfZCvg5RaI7Ky9gfk82NQiD/C+ptGs30 gbog2Q/71kfhue4KtIrecrQnXfd7EiD6eXAThaYWvNqC0hqyD+op3H6/QL3GNEjJgHEea1uB a6UB8+dA088DjJVwr3Q/v0E9ThgYPfz7H03TIPoDPIaqqiREqpjmv8m3ikPot4VClRCJVGt0 1bnFk5Wz6WVzBLLR0XHNEsbjcZ6seGY/PbGviDDumMuo6ZEMsDNtQGg0LHWGh1AfMQHLkIAp MBHk9fczFRO3zTAIH0T9Neq+FkGnRgY4AedQttLLuXPVSazVT1HppSKHW4DQ6Dg0se1jqI+j 1uu+4tsQrvCVM4IqYw4xDpSZ5W5ug+UOj0vWfQ0zFNk+1C5Po97gAIQklGq5FvS86YIS7vNO BqHRRwwlNvN5FdQNVI9aXVOXU0kmpaaqnDoSJe3a2qtNCkxpBfkT+GDzWTFZQY9mBbd09cCW 7h60uAkBhDMDgA+3Fer16ufKIh7CwKoyLevkH/IDtmytbF0OMnH7L/F+J7CFERuX9rsddT+J B51gYFIU8RjheogCv4Ma5fMSQOkVzTuzBQvYUMa7eDAxn+9N9uuGuYPuw5bXuI9jNYvrgyPb Uj2x3euS8Eqvpxyv8zauWZT32AIZQpG4M0o8x878GxxmsmRhHiQPLuF4ezGojgXnRQz0G3/d IqhFx9maTaegpqYWVBrtstPWcEQGODs/jsCzuWsrtCFFramJ8DynqiQIA5BfQ6pO+4JjYxPQ 1z+gUV7rKfYV/bVv6azovOZVq/vY34qBxYxYFp01xf6FyqPlfQIIb2NaJ5u48guo98BMovco pp0XWlAjA4QbUf+NrdoY+yMXCCAkf/DboCe904JPRZTtW0xHreRKAYT9qN/hTikbfO5lH5Jk tWYRVLj4gOBGeN27Qq+wkLuDTgImFUzR2yXr7jcdgzrqFRbHeJGvvYd/n9XsNvgkdJUo5T/w 939k5iBzK/6HfUIPt8GBku2O4d+138F9/gv/ZqL8iQfqYZXBEKmrE1/ltjkv8iiprBEtVJYt 2cRkDFpaGrUHiWcmHpZZQXU6Ikovoenu7oXR8QkOxnhszzUem9LymML4EPdJAhGvFzniBRgU +zAYzhWoyyPsU1jJ79mXecbUIU5HvZWPaxVlPJYDPmZ/9EyBrv096CV8olBHPIet6PkW51jK wAaTD3q8xfGAKdhX+X4MKn6W4oPbF2W61lcHd4HJVFZ7G61E9ueBIWAR5Wxm5rBMsv551DtM FO5yi+u7mi2l2SqRD/dLBrJYl3cyR2nXg/a6a6lPfBpbT7MQaK+XbP8VPp/dQEQDyMUWIDzB 8F1V9OfCVWEEoVccwtbzgOvLgU+BYc6wmsMjoxCLxaCurlazjgG/T5+YWJ15BZvuB3q15WNj 42gFhzQa6uRFM3Se4fGoFqghKmt2C3wSfy1cAv0Is+8S4h/QkAQ4ezXVs6DXTp5sipQeyxZP lCGmLX3C8m8L/t2NNqAx5Cpy+kGfIVqU04Tj3ezgeC8zKC6d9rsUOKIGxn8aCaownlCtgLg3 a7HyNFPQuMkKyyzSvRyEsRoI13BgxCx0oSdy9LNFst9NEhACs5mjOKIqDjaPWVxDggfwH0rW USDta2Y2lc2kIRKplZEJqsPdgLrCNn9hIQQmSvb39PbD0NAIhMMh7f0YFRVBCPr9GqpphvCp iUkYGR3XfEu1gBU0X8dUPAH9CHaJ71hdTh+RclIHsGUyj9ZvOdz/PwQQH2gBxPsswvSHCr7k ww7OSZT2AYHKGcGQ40zLxlF/VcR9XGr6vp8PfZhKb7bgG4GKFOrw/yQss3oL0l0FjvUYt+kK yfF2kWw/zpbUSu5gfy1mAnU/WD95cY7APgx5kvtEbMZ0quALVIA/EGQI5gANhzrqc+oKJz6i ldXyKopWjzoyOgajaPXIevkRiEQtiYpqbxdW9Qio06NTgGYTRVKTSdEaSoFIlO273DhOI6oe DoJkmJ6apZjXF7/DtMk47y4mP0S0OqI0CbStk2mKE/mr8D3F/urugm/Ywuexa5cURx9j09FV BXaigGmVj94mW9ZaiTV8jktgJq+6l2S79Q7cjTi3qwhEyvvuKtn+XRu3wRgs75MsP0yyLMLx A1m7dnLfyueyimEL8wa335oDVaW+W8oApG6BsxDPJKaPp03NWATAtWDORBS2Dg5ZWc88IE4y FSi1xE38If+viH2HuQNXmcAlA+KUZN9GyE2R9BZxDyLFTTMQzZX8yzgg4UTETC9dl8er2EYM +9gieS3SCh38VwxcrWHLY9B/GYXcYBEkE0UGrKCFFest44BiV821hgNtT81sjNYqmYDo+CiE InXad2GKftxeeU4PHPE0FbO9QKX0NxkTCOmFNO9t6tZorccjPVLIU0SjOJF6CfVzKllh8Com x1kpAGeiiH3FShpV0umVIjuWGO0s5AJQnenn2K8S9VOgpxTusNj3dNPg5bfwv5xIvIh7/Dhr ka8DIXfrDdDU/COgINWQWzv1JmB4ZrJZ+KSEoqoUyFm3fhPEtOS+ZTeKlTuPmJU4/E4lArnV IcNFADIj0NpigBOWnENMmlMa5FEo/sWuBIwumvA5XXp/UNliXsiR05XCevLJ9+OAl4wtOJ0R oKbI+yq3pJmR1UoCWd83+8Paa9zQ0g3190J9i7S8jSzo/WgOT0kk0x979TQ9iU+F/v04WGzo 7kW/MGUHQpLXyw3EbkknecHhvu3CD9xZBBAneJQ2coJ1RVxzh8TnHZHc1wUltQhCerCiAdYP BsA/u+5rlNCtlKxbzH+7LNwFqgUdKnD8nS3OmYbcnLAVBTZLLWtWcHvsBuYfMzP4I+SX61FK 49/NfYmeS4xOTkJVJAaByiqZL3gZUsr948nkzh/bNEKKPo/qRDQGm3sHYHBsXKPGBUBIOz5V 7hK3dxw451ZykPD9tSL2pWDKoOn7UglNthKxCocGp00cGTRkuYPOZ6bJZKEognwgBWv82SQE fUo5JpayKso2gCLzY1t0f8lWjKJ8kATGnpcs3x3khQWG/IgH0ndYPwI98R+y2f4yDpz9TLKe 8qs3i4zEGwhCfy+6q9n0dKmESbs9ivK16FR8ME11pHNsFXWwKbCxpw/WftQJfSP684dKQRCS v60+Vm4gvgq5DwYfLqEaMqEGPlpY9mwR550UBoEFYPHWHUF2kQAxwCB8SQgGOX0S/ovcgV/U OpYCZ9ZmJiBCUdPZ+yupAn7pH0Bei3oB2E+FQumDZgvf9XcWFu8Mm0Hh8ybaH2am02lhlYnJ 3GP6ToDbKtmO/OWLcm9an5Cpr3sLmlo1L5KJFvGNeCp10tjE5Cg9Bzg3VlCvsIlOJeDtjzZq VJTK5iQpCiuhNFDfXFjE/xWoqZMHVqkCxhx6f8ViJLaTB4Tv11t0LjP4b5bQLuPXvE/Smasc +FlX5PjMKjwx7gnBaNIjLQIuwY+yEyqyf9KCbTwqoZ/kl/8z6KV8otDEVA/pUcgcdjBN/VC/ IfjjRClvAHnR+P0Ogzw9kJ8fNeQqDl6ZLJFPS8KPDPVrub2Zl2erRjT1Dxu29l1CdLHcYDSs 3Saygh9ugOGJSR2Azq3vyziUXKfM0ZT7t0oa73Sb7Slp/BNh2U1Q/LSBDwp0djfufMss/KEn JdbQLNQJzfk3mrTpThswtvD5VplHOzUDL2/xtsNIXNVGzjmyiOYDUymbLFp9FN/P8zxoUUDj fd5edmE3s2/cDfKcYAWP5uu4rYyigHMl2/4Z9AKLkMP7vBdMKQshsJZXfeNDijo2OgpqJiUz WBCLJx5/88ON3b2Dw9oLYWY9IJIviL9lbCoOb33YCQh03Qp6iuK/4whAqgaLQglRQCdClSVU uPs9U4SNnnM7jdd1MsgoV3coU9KgAOSHSzivUSb1lIkOE51ZyzRxPV8Ljdb7mjrFGFsGRXI8 aqj/Mvmb9Izjp0FPGr/FlLge9Cqg4wQLTOe9hAbll5IdkE6l8cebdXMP2wwChtB1fYctkKwj f9bhoGauF/0BU/2VEvawG6ud/36OZMAoJFdx/xADN0fz8XLSOfTEPr1XsbFlYd7sbui/DaYy mTve3dx97cDoOCxpbYLqcFh7NK3YaicCMUVsyRfs6h+EVCqDA2zRDihR9JNxlHjNTM/mQi7h Rjc/QfE5B37b3ZBf9KsU+G6WF5mG3WOyTGG2urLyr2e4w95rcbyX2N951BRdXcq0zJZyABWA p2GkN9gC6wYqIRAoS7TgI4vlxzOLMCzhbzhieQcUP6ExlcOdLwHTkewzFlMTS8UEJ0qCeE6E ikFuAb2IXBSiv8+B/vjXNBCjE+iLR6LgrwznPeWClvEWpKrHDYyNrxpBCknvTGxrboBIOAz6 C0VVsJvTX6u0QWs6PhGFj7p6YHQyqlXJeDRfsCgwIytRTlH06qQZgPOPR+Zxij+XK9h7Ef8I 6xxsSxdFj9x8U0JJp/ia6NqSDvyMdRytvYB/zLiE3hmU7AjIn6R3Kr/hNHD/HCzKrQT/5loG /WYqbXs+uweMTaWMqTKS3Dk38l/SASHiW6id6J62mPbfwBbxDIlVO4AHmULHpzY1HjM6G+TJ /S08KFGCvavA8eiebmPr+4rQtluZFW3g6HSnDeW+ka+rS7jfNDOsPIo60N+vT82fX4IWRXCu QfoYp+h179AIrP2gUwuw9A6OaLWlFPn0MnU11PhOzxmu39IDa9dvhDH0N2d8QcdwGcTzX4p6 sAhCDejRazoaGZDGc4XDZbaORDv35/D4cqaBGT4P0cUX2Lezmh2cKGQ1zJSOjYDzmcSp9y9i reAO1s8dIGmKGJpD5keA9aS9dJxDQK+pXcDtNsHAehX08Pu4ObRyS/oYeG9IQYsYNAa+oMTC p8D5NJRByM+tGlxsymKferZkVDfaym2aZor0EQd51hfxm1Zz0GRPdjHCfP19PBC+DJKHdKG0 KfcDFpTWx65Bzn6peAza2peAt6LS6tnP01U1e7fWZrhnhkvggj4fhEMVUFVZCeHKoObPU5R7 CgE4EZ2CMbSASQSrVitaPLm5n0CYFw02v04cgQg7iAT4xzF+mKTDgM/PTD5MlDtXeeYIxa5+ a/Y4eGdANYDoyhwL1aEu6ugAxRuwwbZ6AdNe0yKec1RVc2pLs2Au9C76cnBgIito8eSOCYg7 0kzfZ7Gle5st1Dcc7NMAufnLtTCPJuqdv6L8K+oZOa6GAiZqqucnSSkSqiXriwchuQb7KA4f n9uRgEihc6LZO3H08iKwn7SK5Eqmm4Y85nbSeSO/RKgdxj5nOUGOjohyEil+3up0rx0JiM+x n2bIHqA/0vVF9ueMKo9WjgDSujWm7SkCd7fbP+eVUEJ9Xw4KTZXheA8oer75wWJ39O1AjUrB Akp9PA0zuaeD+DsFUMaY7lOOUUzKUwDnVIsAgys7towiGC9X9UH4CnQWTykBF314jHNV+aRi 884iklB5HaUOxOJnoqiLmYZW5bro2pwtqwVr6sr8kw9xlD4NAUUW7TpmSIVyEzEc23+BSlmB R2Zzct8O2KB/ZUtIc3BSIIaoB+XZKGSfZQe9i4FHCeqX3T7oikneRTDS849UTfQpFdRDQM/H ruA+NKX7lcqziNMnELwby5F4/38BBgAk9KPcKlaR9QAAAABJRU5ErkJggg== --------------020802020209010907080704-- --------------050501010101090102070900-- From jricher@mitre.org Tue Apr 17 06:31:17 2012 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 7FD0521F861C for ; Tue, 17 Apr 2012 06:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4F+2LHv8Tpku for ; Tue, 17 Apr 2012 06:31:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1929221F8613 for ; Tue, 17 Apr 2012 06:31:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A088421B0FE4; Tue, 17 Apr 2012 09:31:07 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 90A4021B0FE1; Tue, 17 Apr 2012 09:31:07 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 17 Apr 2012 09:31:07 -0400 Message-ID: <4F8D7076.3040203@mitre.org> Date: Tue, 17 Apr 2012 09:30:30 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: John Bradley References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> <4E1F6AAD24975D4BA5B168042967394366487923@TK5EX14MBXC284.redmond.corp.microsoft.com> <34E26D40-340F-48A9-9761-D0B2B558DB6A@ve7jtb.com> In-Reply-To: <34E26D40-340F-48A9-9761-D0B2B558DB6A@ve7jtb.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] IIW and OAuth 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: Tue, 17 Apr 2012 13:31:17 -0000 It was also my understanding that this was for something outside of IIW, in addition to whatever happens *at* IIW. Nothing's stopping there being various IIW sessions on topic as well, but there's something to be said for getting together for a few hours at a shot without the distractions of the rest of the unconference going on simultaneously. It's worked well before. -- Justin On 04/16/2012 06:28 PM, John Bradley wrote: > I only purchased the Tuesday for IIW because I am tied up Wednesday and Thursday is traditionally digital death or something like that. > > Tuesday is best if it is going to be during IIW hours. Though I thought Hannes was suggesting something outside IIW. > > John B. > On 2012-04-17, at 12:21 AM, Mike Jones wrote: > >> I propose that you schedule this session at IIW on Thursday, as that looks like the time that will garner the greatest participation. >> >> -- Mike >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Axel.Nennker@telekom.de >> Sent: Monday, April 16, 2012 10:55 AM >> To: phil.hunt@oracle.com; hannes.tschofenig@gmx.net >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] IIW and OAuth >> >> Same for me. Tues-Thurs works better for me too. >> Axel >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt >> Sent: Monday, April 16, 2012 6:15 PM >> To: Hannes Tschofenig >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] IIW and OAuth >> >> Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote: >> >>> Hi guys, >>> >>> I was wondering how many of you will be at the upcoming IIW in Mountain View (or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd). >>> >>> I thought it might be good to useful to get together on the Friday after the IIW event for a OAuth breakfast chat. >>> I am sure that there are still a couple of topics that require brainstorming. >>> >>> Drop me a message if you are able and interested. >>> >>> Ciao >>> Hannes >>> >>> PS: Please do not forget to read the Assertion specs so that we can get them out of the door. >>> (And thanks to those who have already read them.) >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 From stephen.farrell@cs.tcd.ie Tue Apr 17 07:45:40 2012 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 1210C21F852A for ; Tue, 17 Apr 2012 07:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QthFGPYWfYMF for ; Tue, 17 Apr 2012 07:45:35 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id ED8B421F852E for ; Tue, 17 Apr 2012 07:45:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 196CF17147B for ; Tue, 17 Apr 2012 15:45:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1334673929; bh=TxXUa5F6nOhGf0025MIzpimr ha7XaEoSguOtM0SvmOA=; b=JxbajI7GAz3h0ASSx0CQ0at4lFdW4dNHot1vO4SE K6xzKStaBA5PRNT549tUifW8nVRh8Ipa8AdhEH/ds7Apn6cCrQNGqLdkx5dZHkxj BAjFWKhKnwzn/rwsfwIQQbfO6ZfwaRdy8ejkMi3CH3cEKdjGMfXpBpWgVFyfo/+n gJl+BGjSW9vS5+2HSphLbgzokCxz67TSYoHLAZSgzTf6i2/JVZW8tNlOtxvsLjTI ayMPvRzC1od226+k4V/LjvHOA0l2tyQtmcRYu/N838h6GfFypoNSaogL7j192x6r zLyekk9DakswO/uVNBQg21ysP8ten6qZTmOysjSaViEsug== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id iv-+XFqW0MM6 for ; Tue, 17 Apr 2012 15:45:29 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 14BD3171477 for ; Tue, 17 Apr 2012 15:45:28 +0100 (IST) Message-ID: <4F8D8208.5040001@cs.tcd.ie> Date: Tue, 17 Apr 2012 15:45:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] web sso study... 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: Tue, 17 Apr 2012 14:45:40 -0000 Hi all, A recent news article [1] was brought to my attention this week that's about a paper [2] which I've just read. While it mostly deals with implementation and integration flaws, I'm wondering if there's anything in there that could benefit any of the oauth drafts. Anyone had a look at that already? Be interesting if any similar analysis has been done on any oauth 1.0 or 2.0 sites or implementations. Ta, S. [1] http://www.itbusiness.ca/it/client/en/CDN/News.asp?id=66741 [2] https://research.microsoft.com/pubs/160659/websso-final.pdf From ve7jtb@ve7jtb.com Tue Apr 17 07:57:34 2012 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 4B11C21F8551 for ; Tue, 17 Apr 2012 07:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDDoywqqGoBk for ; Tue, 17 Apr 2012 07:57:29 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3E411E8080 for ; Tue, 17 Apr 2012 07:57:28 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so500058wib.13 for ; Tue, 17 Apr 2012 07:57:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=dOpFgJFrd+QA/LEt2VTSc//O13VWt+oyu0yHHzZbgAE=; b=VCQHCWfHwp0Yk92u5TTqkOfMJ38sgXKfr5fZbevFCQ5v+ZXpMb/rtclXR2F1qmY9gQ Im0rsIXph6YfDcz11gszEbihYZDWti/YOuwbpfDIxBuCCyrd4SFiISAExeSeNCQiy0Qa miiK8RdTi9ilC02Pm1ya0yVIdyFCJqZCVjBM/bQ/hVteAZd/J7xQ5lPwOVmStotaWfsA q3kb8BqegY/dbJ8nfMSQdrXHyVRyDv3TJYCNUp03JFwc1LHc+KmKafaZDjt6ehT1St/p TVzGQKmm1ufkkc3WHINssAc3cm9VeBeOF3BtqFQPmbgClu7mckuqHZo0DW+04z9zGzKb GUfw== Received: by 10.180.81.166 with SMTP id b6mr8022037wiy.0.1334674648310; Tue, 17 Apr 2012 07:57:28 -0700 (PDT) Received: from [10.6.1.133] (nat-VI.gw1.ush2.tnib.de. [86.110.65.2]) by mx.google.com with ESMTPS id u9sm27428062wix.0.2012.04.17.07.57.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 07:57:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_D66F8AAA-D486-4EB7-98DD-1B967044B786"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4F8D8208.5040001@cs.tcd.ie> Date: Tue, 17 Apr 2012 16:57:24 +0200 Message-Id: References: <4F8D8208.5040001@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnUktCZsVHm180VrmOjil8JorOkGs8wm7IwdpVIpKJ4izM3ExGADOXTU60cytmJXmIubJHn Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] web sso study... 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: Tue, 17 Apr 2012 14:57:34 -0000 --Apple-Mail=_D66F8AAA-D486-4EB7-98DD-1B967044B786 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I posted to my blog about a significant implementation flaw made by = people using Facebook's OAuth 2 implementation. I understand that Facebook is fixing it in there own code, but many = clients are exploitable. For those interested. http://www.thread-safe.com/2012/04/followup-on-oauth-facebook-login.html The flaw is not in the spec but in implementations.=20 John B. On 2012-04-17, at 4:45 PM, Stephen Farrell wrote: >=20 > Hi all, >=20 > A recent news article [1] was brought to my attention this week > that's about a paper [2] which I've just read. While it mostly > deals with implementation and integration flaws, I'm wondering > if there's anything in there that could benefit any of the > oauth drafts. Anyone had a look at that already? >=20 > Be interesting if any similar analysis has been done on any > oauth 1.0 or 2.0 sites or implementations. >=20 > Ta, > S. >=20 > [1] http://www.itbusiness.ca/it/client/en/CDN/News.asp?id=3D66741 > [2] https://research.microsoft.com/pubs/160659/websso-final.pdf > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D66F8AAA-D486-4EB7-98DD-1B967044B786 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx NzE0NTcyNVowIwYJKoZIhvcNAQkEMRYEFIFLJNJK/cFSP5JdpPyuc22u7aGiMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AAOhBY0FWvH24+uUwxOpXvu2Wn/rWixSPnN/Lf7Wm8uslViamiosa/9tOR6MYioQAgDdiwPcoOA2 DPVOZcb+0RufLts8hseNGp4skP0Esc7epJg0fGRczsXl4JZ3Agqufh5JxC66r0bQ3epdrfvrJ9bv j1sJMgJFfHa3NSiqiIVc3+mi7QIulynmJg0DzWlBvkicswFgFsMrHuXOk3I9AzSa4bxRHypE7sLN UwF5k9dawqhMqtWfqRnyS/GgGh6boCRsUHRqJ4om/1a1Oisro28WWcPT3W3Tv0skZxUv12j0R7iq eNb5FPAHWNwEd4hkCZ9ACZg20lMxESIGMjJkmXEAAAAAAAA= --Apple-Mail=_D66F8AAA-D486-4EB7-98DD-1B967044B786-- From simon@josefsson.org Mon Apr 16 14:27:15 2012 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 A141921F84D9 for ; Mon, 16 Apr 2012 14:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.851 X-Spam-Level: X-Spam-Status: No, score=-99.851 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzPMi7TrMrbH for ; Mon, 16 Apr 2012 14:27:14 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8367A21F84D8 for ; Mon, 16 Apr 2012 14:27:13 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3GLR5jQ000496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2012 23:27:07 +0200 From: Simon Josefsson To: References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> <1886AC50-18EF-4511-99F2-6DC44F415759@oracle.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120416:oauth@ietf.org::P/AfuKd2DXD5u2jM:1cKF X-Hashcash: 1:22:120416:phil.hunt@oracle.com::aoXdJA1vj6BwennW:5DC9 X-Hashcash: 1:22:120416:axel.nennker@telekom.de::j3OdpFmhlk3Ig48c:7TEj X-Hashcash: 1:22:120416:hannes.tschofenig@gmx.net::B981lmQZvJOWTWzs:Qu/p Date: Mon, 16 Apr 2012 23:27:05 +0200 In-Reply-To: (Axel Nennker's message of "Mon, 16 Apr 2012 19:54:42 +0200") Message-ID: <87d377jrkm.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 17 Apr 2012 08:13:02 -0700 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] IIW and OAuth 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, 16 Apr 2012 21:27:15 -0000 I'll be at IIW and it would be nice to catch up on OAuth work. I'm going home Thursday evening, so I prefer Tues-Thurs. /Simon writes: > Same for me. Tues-Thurs works better for me too. > Axel > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Phil Hunt > Sent: Monday, April 16, 2012 6:15 PM > To: Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] IIW and OAuth > > Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote: > >> Hi guys, >> >> I was wondering how many of you will be at the upcoming IIW in Mountain View (or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd). >> >> I thought it might be good to useful to get together on the Friday after the IIW event for a OAuth breakfast chat. >> I am sure that there are still a couple of topics that require brainstorming. >> >> Drop me a message if you are able and interested. >> >> Ciao >> Hannes >> >> PS: Please do not forget to read the Assertion specs so that we can get them out of the door. >> (And thanks to those who have already read them.) >> >> _______________________________________________ >> 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 From tbray@textuality.com Mon Apr 16 15:33:02 2012 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 61F4721F85C5 for ; Mon, 16 Apr 2012 15:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dA9RE+GJiUz for ; Mon, 16 Apr 2012 15:33:01 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01421F85BB for ; Mon, 16 Apr 2012 15:33:01 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so3234364obb.31 for ; Mon, 16 Apr 2012 15:33:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=Jh9eoJumgfbsUh1osrXq8WpUdu6PbdFr+qyHpxHP3S0=; b=eBWIOUNye+Lz21ZtUsycz1IoxkctWXbVXSqGnkOIQXUTw5kIREIWlg0RC/qxtHjsJf hractVIwrQzaoz0fheE8loanDrjyVq87yTHXXnVqESxJnozS7lbutIbUvvPxdKwaDpUX og/x9G9DX8ODxgDGK5jzrmzizD2KlHRbnQx+ALLEY/9kn00Wek0MXvwaajSvzBVt/K1O LFRvycipcfrRnfTabaFkqdniUvS7A0Yt8gLLTgXwlv0cxxTTLSRyF80x2f5BzjjNlX7K YXSJmZ76AH/CwXcYMDMIcBcTmggGCHl/7glIMQoforrfo3thVi0TCpuaRTsN9OycLWKk 30BQ== MIME-Version: 1.0 Received: by 10.182.113.42 with SMTP id iv10mr18448763obb.18.1334615581037; Mon, 16 Apr 2012 15:33:01 -0700 (PDT) Received: by 10.182.29.6 with HTTP; Mon, 16 Apr 2012 15:33:00 -0700 (PDT) X-Originating-IP: [2620:0:1000:2104:a518:3c4a:d054:5bd6] In-Reply-To: <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> Date: Mon, 16 Apr 2012 15:33:00 -0700 Message-ID: From: Tim Bray To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl49kOgc4UQ/1ttp+Z1MnE8/4Hb2ST+bhp9YbVaumuKXv+x2h9yO0l7EZ3nPUtsn0L01Aet X-Mailman-Approved-At: Tue, 17 Apr 2012 08:13:02 -0700 Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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, 16 Apr 2012 22:33:02 -0000 What is the deployment status of these two specs? Is either deployed much at all? -T On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy w= rote: >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.or= g] On Behalf Of Stephen Farrell >> Sent: Friday, April 13, 2012 9:23 AM >> To: oauth@ietf.org WG >> Cc: Apps Discuss >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discove= ry (SWD) >> >> So Hannes and Derek and I have been discussing this with the Apps ADs >> and Apps-area WG chairs. I've also read the docs now, and after all >> that we've decided that this topic (what to do with swd and webfinger) >> is best handled in the apps area and not in the oauth WG. >> >> The logic for that is that 1) the two proposals are doing the same >> thing and we don't want two different standards for that, b) this is >> not an oauth-specific thing nor is it a general security thing, and c) >> there is clearly already interest in the topic in the apps area so its >> reasonable for the oauth wg to use that when its ready. >> >> The appsawg chairs and apps ADs are ok with the work being done there. >> >> So:- >> >> - I've asked the oauth chairs to take doing work on swd >> =A0 out of the proposed new charter >> - It may be that you want to add something saying that >> =A0 oauth will use the results of work in the applications >> =A0 area on a web discovery protocol as a basis for doing >> =A0 the dynamic client registration work here >> - Discussion of webfinger and swd should move over to >> =A0 the apps-discuss list >> - Note: this is not picking one or the other approach, >> =A0 the plan is that the apps area will do any selection >> =A0 needed and figure out the best starting point for a >> =A0 standards-track RFC on web discovery and we'll use their >> =A0 fine work for doing more with oauth. > > Thank you Stephen, I think. =A0:-) > > So the discussion on apps-discuss now should be focused on which of the t= wo should be the basis for forward progress. =A0I've placed both documents = in "Call for Adoption" state in the datatracker for appsawg. > > Let the games begin. > > -MSK > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From wmills@yahoo-inc.com Tue Apr 17 08:59:35 2012 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 2905A21F8566 for ; Tue, 17 Apr 2012 08:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.152 X-Spam-Level: X-Spam-Status: No, score=-17.152 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6hScAo98VmV for ; Tue, 17 Apr 2012 08:59:30 -0700 (PDT) Received: from nm18.bullet.mail.ac4.yahoo.com (nm18.bullet.mail.ac4.yahoo.com [98.139.52.215]) by ietfa.amsl.com (Postfix) with SMTP id 6112521F8592 for ; Tue, 17 Apr 2012 08:59:30 -0700 (PDT) Received: from [98.139.52.195] by nm18.bullet.mail.ac4.yahoo.com with NNFMP; 17 Apr 2012 15:59:25 -0000 Received: from [98.139.52.174] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 17 Apr 2012 15:59:25 -0000 Received: from [127.0.0.1] by omp1057.mail.ac4.yahoo.com with NNFMP; 17 Apr 2012 15:59:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 694284.16483.bm@omp1057.mail.ac4.yahoo.com Received: (qmail 64586 invoked by uid 60001); 17 Apr 2012 15:59:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334678365; bh=zF+nij9C2liRnBP2Eo/93EzLZ6LLV5S69XAKR5ks4xQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Y324WlWUGolkojFeiGZvf8HlZ3orMdLPsEZvq53Rj6vPYcnU/IJZN00YdZbzsalI/KeWtQD7TRCFd5UcfY+Z9l1zXu1mmLr1351zt0SprsupekRpOSix/xRZVpVs6hkveZqVS+14TUIU00IJ3C7dhkit7o655S455+u0vc8EeSI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fmGr4+pX6Ja00kAn1N6v54B5HeGU1Xr8iT4id1pdfE21TkSJJ9u2+P9erGVOFN1qZ8MWlLqaRAcIDsSMyHgFAHiAIj6RjzFfRuteOjYjn6FZZs2W601KnC/CINEy4D80ztpvPOgx3jGNk+WvQM77T5cO+1ldUUSOhNXVdBBzNiI=; X-YMail-OSG: 26FN7YEVM1k2_SEcdGbckB8zLrQoA9FOTKl0kJd8Mfo5YjK _KlyEGgSCx4hk8MSUYO.SQ2of74SIWoubdVr1k7aJ95b9MpvNhwYg9nzc7a_ 9LjUwKu3MqQBXk0ocAIwqca4.G_alRSznzX3BP0TmIBY19GvNiB2gwj0TCr1 h.TJlN5asoEf5WQULQRbpPUQjP9w58mqNibpu3S7mLg3WFvFYm9tMWEqtjZL _RjEGIoWp_ztNFNSUqurcZkhAZqTc3tCiEAmHgHL2SqeR8n7IKEQiPp_qNgB OW_EEbBXt910pYnORoJY16HAiLG3r8h1HIj_fMUP0kCtzATkuzittTypEnSx z_JmvZktckkZ1QKi6qHUWCYInOpFGyhpkLAxgJ0Q.rpS5psgo2nJxp1heTH1 rID.OZhOhcdPbgu3cpj8zWJISBfjThpk3i3G3eQkZelwGgjQAjD90F1UEvDf a_LWaetJDZ0DhyKXKntnnsTUtkchoLX5pgWj7H34v0sft6TcdKhx.0iIw1PB mv2_bDKYZ.9x856k10D3OVLGTcwWQvWtWW.8wurt6pG0paBGo3Wf9FR8jFR8 Kq4vMmoftLFCuQm6SKNiUllt19pt9SvNlF6fjuj_ldwc17xn0kG3y1a5HqqZ aibBQ15P33oPauGpHdI.bcX0tgbvQgU7msMpwO6ZIe85NAMcP2u9hzpj1HVN 1ZwmvnWFJPUKQ3g_yh986rvYxqMjetf_cktEB_KnXRymqwYEkh1clN6ij9ki Lqrvi_4cyv7GO6BbacJTqLwZmyspl2iSlpFSUJAjhew-- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Tue, 17 Apr 2012 08:59:24 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <4F8D8208.5040001@cs.tcd.ie> Message-ID: <1334678364.98662.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 17 Apr 2012 08:59:24 -0700 (PDT) From: William Mills To: John Bradley , Stephen Farrell In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-1156706518-1334678364=:98662" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] web sso study... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 15:59:35 -0000 --258328648-1156706518-1334678364=:98662 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, we encountered this problem doing a binding between FB and other acco= unts.=A0 We found that FB actually used a valid browser cookie rather than = serving back the needed auth page we wanted for the user.=A0 We had to work= around this by calling their un-CSRF protected sign-out link first.=A0 =0A= =0A=0AIt's a very real, very bad problem.=0A=0A-bill=0A=0A=0A=0A=0A>_______= _________________________=0A> From: John Bradley =0A>To:= Stephen Farrell =0A>Cc: "oauth@ietf.org" =0A>Sent: Tuesday, April 17, 2012 7:57 AM=0A>Subject: Re: [OAUT= H-WG] web sso study...=0A> =0A>I posted to my blog about a significant impl= ementation flaw made by people using Facebook's=A0 OAuth 2 implementation.= =0A>=0A>I understand that Facebook is fixing it in there own code, but many= clients are exploitable.=0A>=0A>For those interested.=0A>http://www.thread= -safe.com/2012/04/followup-on-oauth-facebook-login.html=0A>=0A>The flaw is = not in the spec but in implementations. =0A>=0A>John B.=0A>=0A>On 2012-04-1= 7, at 4:45 PM, Stephen Farrell wrote:=0A>=0A>> =0A>> Hi all,=0A>> =0A>> A r= ecent news article [1] was brought to my attention this week=0A>> that's ab= out a paper [2] which I've just read. While it mostly=0A>> deals with imple= mentation and integration flaws, I'm wondering=0A>> if there's anything in = there that could benefit any of the=0A>> oauth drafts. Anyone had a look at= that already?=0A>> =0A>> Be interesting if any similar analysis has been d= one on any=0A>> oauth 1.0 or 2.0 sites or implementations.=0A>> =0A>> Ta,= =0A>> S.=0A>> =0A>> [1] http://www.itbusiness.ca/it/client/en/CDN/News.asp?= id=3D66741=0A>> [2] https://research.microsoft.com/pubs/160659/websso-final= .pdf=0A>> _______________________________________________=0A>> OAuth mailin= g list=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/oauth= =0A>=0A>=0A>_______________________________________________=0A>OAuth mailin= g list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>= =0A>=0A> --258328648-1156706518-1334678364=:98662 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, we encountered this problem doing a binding between FB and other ac= counts.  We found that FB actually used a valid browser cookie rather = than serving back the needed auth page we wanted for the user.  We had= to work around this by calling their un-CSRF protected sign-out link first= . 

It's a very= real, very bad problem.

-bill

=
From: John Bradley <ve7jtb@ve7jtb.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie= >
Cc: "oauth@ietf.o= rg" <oauth@ietf.org>
Sent:= Tuesday, April 17, 2012 7:57 AM
Subject: Re: [OAUTH-WG] web sso study...
 =

=0AI posted to my blog about a significant implementation flaw m= ade by people using Facebook's  OAuth 2 implementation.

I unde= rstand that Facebook is fixing it in there own code, but many clients are e= xploitable.

For those interested.
http://www.thread-safe.com/2012= /04/followup-on-oauth-facebook-login.html

The flaw is not in the spe= c but in implementations.

John B.

On 2012-04-17, at 4:45 PM,= Stephen Farrell wrote:

>
> Hi all,
>
> A rec= ent news article [1] was brought to my attention this week
> that's a= bout a paper [2] which I've just read. While it mostly
> deals with i= mplementation and integration flaws, I'm wondering
> if there's anyth= ing in there that could benefit any of the
> oauth drafts. Anyone had= a look at that already?
>
> Be interesting if any similar ana= lysis has been done on any
> oauth 1.0 or 2.0 sites or implementations.
>
> Ta,
> S.
>
> [1] http= ://www.itbusiness.ca/it/client/en/CDN/News.asp?id=3D66741
> [2] https://research.microsoft.com/pubs/160659/websso-final.pdf=
> _______________________________________________
> OAuth mail= ing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/o= auth


_______________________________________________
OAut= h mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=


--258328648-1156706518-1334678364=:98662-- From Jeff.Hodges@KingsMountain.com Tue Apr 17 10:15:13 2012 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 046C711E80A3 for ; Tue, 17 Apr 2012 10:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.006 X-Spam-Level: X-Spam-Status: No, score=-99.006 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPc7bjGndNCf for ; Tue, 17 Apr 2012 10:15:08 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 7E28711E8074 for ; Tue, 17 Apr 2012 10:15:08 -0700 (PDT) Received: (qmail 2412 invoked by uid 0); 17 Apr 2012 17:15:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 17 Apr 2012 17:15:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=jQps71r+9Z15qSpQHP66D7aurstEBLMIB/VvOprX8ig=; b=RqksKmWMXsDIJkfyTmcOSTgK5OxCBAx6S2F06x8F1Y83x7lLSPc0v8n3e9HYPSEIGbaO+G6bCaPNbjcG0xHPiMYPx1Ik4DazMQBXIun7VUaEsv1Jm0xzPP941UdzpLf2; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.216]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SKBze-0000U0-DQ for oauth@ietf.org; Tue, 17 Apr 2012 11:15:06 -0600 Message-ID: <4F8DA518.8010903@KingsMountain.com> Date: Tue, 17 Apr 2012 10:15:04 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF oauth WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [OAUTH-WG] web sso study... 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: Tue, 17 Apr 2012 17:15:13 -0000 Note that the authors of the paper have a website up where one can submit traces to their "Browser Relayed Messages (BRM)" analyzer, plus the obligate forum etc. http://sso-analysis.org/ HTH, =JeffH From romeda@gmail.com Tue Apr 17 15:54:23 2012 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 35A5021F852D; Tue, 17 Apr 2012 15:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.377 X-Spam-Level: X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqTP-fZ29tDN; Tue, 17 Apr 2012 15:54:18 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D943821F852C; Tue, 17 Apr 2012 15:54:17 -0700 (PDT) Received: by lagj5 with SMTP id j5so5642931lag.31 for ; Tue, 17 Apr 2012 15:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KVvTDcsCTqrTPjX1UoedGQ/HsWpKxCa3FQNHM5utoZ8=; b=C2X4OMllskZo/koFjKCoQ+TA5ZaO1upNz0qDi4uWHTdCAjHjO7srwNGzILtRl4tr9/ Yhn9/NRXdZ0B3rjMd+hD6yDiUb3oZ9zxp04k7Q7MO4j/2RG2QdEf2BoxGypxuM9zxRcx p3mO5+CZRaRKbQ5f3SYneFB+b3qy2GP/0tsKXarTmPoLCrZvjZgcW5lhlZnzYrHuidor 0rMCC72kuuVE3yMlN6griLxtkbMZGeLfQRH/Qj9vriq5neu1E+U83odNRnYujM0EB+z4 I7cVt4gyCIDNSVUMdf7ZnggavTQBsMWwRwjCLQZInZH76xPvSWGqrHiP0jify3EIKxRN jGLw== MIME-Version: 1.0 Received: by 10.112.47.66 with SMTP id b2mr10889lbn.35.1334703256765; Tue, 17 Apr 2012 15:54:16 -0700 (PDT) Received: by 10.152.4.166 with HTTP; Tue, 17 Apr 2012 15:54:16 -0700 (PDT) Received: by 10.152.4.166 with HTTP; Tue, 17 Apr 2012 15:54:16 -0700 (PDT) In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> Date: Tue, 17 Apr 2012 18:54:16 -0400 Message-ID: From: Blaine Cook To: Tim Bray Content-Type: multipart/alternative; boundary=bcaec554055e80079404bde7d18d Cc: "oauth@ietf.org WG" , apps-discuss@ietf.org Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Tue, 17 Apr 2012 22:54:23 -0000 --bcaec554055e80079404bde7d18d Content-Type: text/plain; charset=UTF-8 That's a tricky question - maybe one google can help answer? There are a bunch of projects using webfinger, including status.net, ostatus in general, diaspora, unhosted, freedombox(?), and I'm sure others, but I have no idea how that translates into actual users or profiles. Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't been much movement, I think due to the chicken and egg nature of adoption around decentralized tools. b. On Apr 17, 2012 11:13 AM, "Tim Bray" wrote: > What is the deployment status of these two specs? Is either deployed > much at all? -T > > On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy > wrote: > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell > >> Sent: Friday, April 13, 2012 9:23 AM > >> To: oauth@ietf.org WG > >> Cc: Apps Discuss > >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery (SWD) > >> > >> So Hannes and Derek and I have been discussing this with the Apps ADs > >> and Apps-area WG chairs. I've also read the docs now, and after all > >> that we've decided that this topic (what to do with swd and webfinger) > >> is best handled in the apps area and not in the oauth WG. > >> > >> The logic for that is that 1) the two proposals are doing the same > >> thing and we don't want two different standards for that, b) this is > >> not an oauth-specific thing nor is it a general security thing, and c) > >> there is clearly already interest in the topic in the apps area so its > >> reasonable for the oauth wg to use that when its ready. > >> > >> The appsawg chairs and apps ADs are ok with the work being done there. > >> > >> So:- > >> > >> - I've asked the oauth chairs to take doing work on swd > >> out of the proposed new charter > >> - It may be that you want to add something saying that > >> oauth will use the results of work in the applications > >> area on a web discovery protocol as a basis for doing > >> the dynamic client registration work here > >> - Discussion of webfinger and swd should move over to > >> the apps-discuss list > >> - Note: this is not picking one or the other approach, > >> the plan is that the apps area will do any selection > >> needed and figure out the best starting point for a > >> standards-track RFC on web discovery and we'll use their > >> fine work for doing more with oauth. > > > > Thank you Stephen, I think. :-) > > > > So the discussion on apps-discuss now should be focused on which of the > two should be the basis for forward progress. I've placed both documents > in "Call for Adoption" state in the datatracker for appsawg. > > > > Let the games begin. > > > > -MSK > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --bcaec554055e80079404bde7d18d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That's a tricky question - maybe one google can help answer? There a= re a bunch of projects using webfinger, including status.net, ostatus in general, diaspora, unhosted, freedombox(?),= and I'm sure others, but I have no idea how that translates into actua= l users or profiles.

Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn'= ;t been much movement, I think due to the chicken and egg nature of adoptio= n around decentralized tools.

b.

On Apr 17, 2012 11:13 AM, "Tim Bray" &= lt;tbray@textuali= ty.com> wrote:
msk@cloudmark.com> wrote:
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]= On Behalf Of Stephen Farrell
>> Sent: Friday, April 13, 2012 9:23 AM
>> To: oauth@ietf= .org WG
>> Cc: Apps Discuss
>> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web D= iscovery (SWD)
>>
>> So Hannes and Derek and I have been discussing this with the Apps = ADs
>> and Apps-area WG chairs. I've also read the docs now, and afte= r all
>> that we've decided that this topic (what to do with swd and we= bfinger)
>> is best handled in the apps area and not in the oauth WG.
>>
>> The logic for that is that 1) the two proposals are doing the same=
>> thing and we don't want two different standards for that, b) t= his is
>> not an oauth-specific thing nor is it a general security thing, an= d c)
>> there is clearly already interest in the topic in the apps area so= its
>> reasonable for the oauth wg to use that when its ready.
>>
>> The appsawg chairs and apps ADs are ok with the work being done th= ere.
>>
>> So:-
>>
>> - I've asked the oauth chairs to take doing work on swd
>> =C2=A0 out of the proposed new charter
>> - It may be that you want to add something saying that
>> =C2=A0 oauth will use the results of work in the applications
>> =C2=A0 area on a web discovery protocol as a basis for doing
>> =C2=A0 the dynamic client registration work here
>> - Discussion of webfinger and swd should move over to
>> =C2=A0 the apps-discuss list
>> - Note: this is not picking one or the other approach,
>> =C2=A0 the plan is that the apps area will do any selection
>> =C2=A0 needed and figure out the best starting point for a
>> =C2=A0 standards-track RFC on web discovery and we'll use thei= r
>> =C2=A0 fine work for doing more with oauth.
>
> Thank you Stephen, I think. =C2=A0:-)
>
> So the discussion on apps-discuss now should be focused on which of th= e two should be the basis for forward progress. =C2=A0I've placed both = documents in "Call for Adoption" state in the datatracker for app= sawg.
>
> Let the games begin.
>
> -MSK
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--bcaec554055e80079404bde7d18d-- From Michael.Jones@microsoft.com Tue Apr 17 16:25:01 2012 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 DD4F321F8497; Tue, 17 Apr 2012 16:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.886 X-Spam-Level: X-Spam-Status: No, score=-3.886 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvXt4cbaJfsE; Tue, 17 Apr 2012 16:24:57 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 3D53D21F8498; Tue, 17 Apr 2012 16:24:57 -0700 (PDT) Received: from mail197-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Apr 2012 23:24:56 +0000 Received: from mail197-ch1 (localhost [127.0.0.1]) by mail197-ch1-R.bigfish.com (Postfix) with ESMTP id 9A5B6120488; Tue, 17 Apr 2012 23:24:56 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zz9371Ic89bh542M1432Nc857h98dKzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail197-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail197-ch1 (localhost.localdomain [127.0.0.1]) by mail197-ch1 (MessageSwitch) id 1334705093495786_30954; Tue, 17 Apr 2012 23:24:53 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail197-ch1.bigfish.com (Postfix) with ESMTP id 5EB2A4601EB; Tue, 17 Apr 2012 23:24:53 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Apr 2012 23:24:53 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Tue, 17 Apr 2012 23:24:46 +0000 From: Mike Jones To: Blaine Cook , Tim Bray Thread-Topic: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHO0LA6pvK3gX3U+Yi1VN9w4mnZafpy3A Date: Tue, 17 Apr 2012 23:24:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436648BF09@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436648BF09TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" , "apps-discuss@ietf.org" Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Tue, 17 Apr 2012 23:25:02 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436648BF09TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBrbm93IHRoYXQgNyBvZiB0aGUgOCBwdWJsaWMgcGFydGljaXBhbnRzIGluIHRoZSBjdXJyZW50 IE9wZW5JRCBDb25uZWN0IGludGVyb3AgdGVzdGluZyBoYXZlIGltcGxlbWVudGVkIFNXRCBhdCB0 aGlzIHBvaW50LiAgKEkga25vdyBvZiBzZXZlcmFsIG1vcmUgd2hv4oCZdmUgYnVpbHQgaXQgYXMg d2VsbCBidXQgaGF2ZW7igJl0IGNob3NlbiB0byBtYWtlIHRoZWlyIGludGVyb3AgdGVzdCByZXN1 bHRzIHB1YmxpYyB5ZXQuKSAgVGhlcmUgYXJlIGxpa2VseSBvdGhlciBpbXBsZW1lbnRhdGlvbnMg SeKAmW0gdW5hd2FyZSBvZi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJsYWlu ZSBDb29rDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiAzOjU0IFBNDQpUbzogVGltIEJy YXkNCkNjOiBvYXV0aEBpZXRmLm9yZyBXRzsgYXBwcy1kaXNjdXNzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBbYXBwcy1kaXNjdXNzXSBXZWIgRmluZ2VyIHZzLiBTaW1wbGUgV2Vi IERpc2NvdmVyeSAoU1dEKQ0KDQoNClRoYXQncyBhIHRyaWNreSBxdWVzdGlvbiAtIG1heWJlIG9u ZSBnb29nbGUgY2FuIGhlbHAgYW5zd2VyPyBUaGVyZSBhcmUgYSBidW5jaCBvZiBwcm9qZWN0cyB1 c2luZyB3ZWJmaW5nZXIsIGluY2x1ZGluZyBzdGF0dXMubmV0PGh0dHA6Ly9zdGF0dXMubmV0Piwg b3N0YXR1cyBpbiBnZW5lcmFsLCBkaWFzcG9yYSwgdW5ob3N0ZWQsIGZyZWVkb21ib3goPyksIGFu ZCBJJ20gc3VyZSBvdGhlcnMsIGJ1dCBJIGhhdmUgbm8gaWRlYSBob3cgdGhhdCB0cmFuc2xhdGVz IGludG8gYWN0dWFsIHVzZXJzIG9yIHByb2ZpbGVzLg0KDQpHbWFpbCwgYW9sLCBhbmQgeWFob28g YWxsIHB1dCB1cCB3ZWJmaW5nZXIgZW5kcG9pbnRzLCBidXQgdGhlcmUgaGFzbid0IGJlZW4gbXVj aCBtb3ZlbWVudCwgSSB0aGluayBkdWUgdG8gdGhlIGNoaWNrZW4gYW5kIGVnZyBuYXR1cmUgb2Yg YWRvcHRpb24gYXJvdW5kIGRlY2VudHJhbGl6ZWQgdG9vbHMuDQoNCmIuDQpPbiBBcHIgMTcsIDIw MTIgMTE6MTMgQU0sICJUaW0gQnJheSIgPHRicmF5QHRleHR1YWxpdHkuY29tPG1haWx0bzp0YnJh eUB0ZXh0dWFsaXR5LmNvbT4+IHdyb3RlOg0KV2hhdCBpcyB0aGUgZGVwbG95bWVudCBzdGF0dXMg b2YgdGhlc2UgdHdvIHNwZWNzPyAgSXMgZWl0aGVyIGRlcGxveWVkDQptdWNoIGF0IGFsbD8gIC1U DQoNCk9uIEZyaSwgQXByIDEzLCAyMDEyIGF0IDEwOjQ1IEFNLCBNdXJyYXkgUy4gS3VjaGVyYXd5 IDxtc2tAY2xvdWRtYXJrLmNvbTxtYWlsdG86bXNrQGNsb3VkbWFyay5jb20+PiB3cm90ZToNCj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFN0ZXBoZW4gRmFycmVsbA0KPj4gU2VudDogRnJpZGF5 LCBBcHJpbCAxMywgMjAxMiA5OjIzIEFNDQo+PiBUbzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoQGlldGYub3JnPiBXRw0KPj4gQ2M6IEFwcHMgRGlzY3Vzcw0KPj4gU3ViamVjdDogUmU6IFth cHBzLWRpc2N1c3NdIFtPQVVUSC1XR10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdlYiBEaXNjb3Zl cnkgKFNXRCkNCj4+DQo+PiBTbyBIYW5uZXMgYW5kIERlcmVrIGFuZCBJIGhhdmUgYmVlbiBkaXNj dXNzaW5nIHRoaXMgd2l0aCB0aGUgQXBwcyBBRHMNCj4+IGFuZCBBcHBzLWFyZWEgV0cgY2hhaXJz LiBJJ3ZlIGFsc28gcmVhZCB0aGUgZG9jcyBub3csIGFuZCBhZnRlciBhbGwNCj4+IHRoYXQgd2Un dmUgZGVjaWRlZCB0aGF0IHRoaXMgdG9waWMgKHdoYXQgdG8gZG8gd2l0aCBzd2QgYW5kIHdlYmZp bmdlcikNCj4+IGlzIGJlc3QgaGFuZGxlZCBpbiB0aGUgYXBwcyBhcmVhIGFuZCBub3QgaW4gdGhl IG9hdXRoIFdHLg0KPj4NCj4+IFRoZSBsb2dpYyBmb3IgdGhhdCBpcyB0aGF0IDEpIHRoZSB0d28g cHJvcG9zYWxzIGFyZSBkb2luZyB0aGUgc2FtZQ0KPj4gdGhpbmcgYW5kIHdlIGRvbid0IHdhbnQg dHdvIGRpZmZlcmVudCBzdGFuZGFyZHMgZm9yIHRoYXQsIGIpIHRoaXMgaXMNCj4+IG5vdCBhbiBv YXV0aC1zcGVjaWZpYyB0aGluZyBub3IgaXMgaXQgYSBnZW5lcmFsIHNlY3VyaXR5IHRoaW5nLCBh bmQgYykNCj4+IHRoZXJlIGlzIGNsZWFybHkgYWxyZWFkeSBpbnRlcmVzdCBpbiB0aGUgdG9waWMg aW4gdGhlIGFwcHMgYXJlYSBzbyBpdHMNCj4+IHJlYXNvbmFibGUgZm9yIHRoZSBvYXV0aCB3ZyB0 byB1c2UgdGhhdCB3aGVuIGl0cyByZWFkeS4NCj4+DQo+PiBUaGUgYXBwc2F3ZyBjaGFpcnMgYW5k IGFwcHMgQURzIGFyZSBvayB3aXRoIHRoZSB3b3JrIGJlaW5nIGRvbmUgdGhlcmUuDQo+Pg0KPj4g U286LQ0KPj4NCj4+IC0gSSd2ZSBhc2tlZCB0aGUgb2F1dGggY2hhaXJzIHRvIHRha2UgZG9pbmcg d29yayBvbiBzd2QNCj4+ICAgb3V0IG9mIHRoZSBwcm9wb3NlZCBuZXcgY2hhcnRlcg0KPj4gLSBJ dCBtYXkgYmUgdGhhdCB5b3Ugd2FudCB0byBhZGQgc29tZXRoaW5nIHNheWluZyB0aGF0DQo+PiAg IG9hdXRoIHdpbGwgdXNlIHRoZSByZXN1bHRzIG9mIHdvcmsgaW4gdGhlIGFwcGxpY2F0aW9ucw0K Pj4gICBhcmVhIG9uIGEgd2ViIGRpc2NvdmVyeSBwcm90b2NvbCBhcyBhIGJhc2lzIGZvciBkb2lu Zw0KPj4gICB0aGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIHdvcmsgaGVyZQ0KPj4gLSBE aXNjdXNzaW9uIG9mIHdlYmZpbmdlciBhbmQgc3dkIHNob3VsZCBtb3ZlIG92ZXIgdG8NCj4+ICAg dGhlIGFwcHMtZGlzY3VzcyBsaXN0DQo+PiAtIE5vdGU6IHRoaXMgaXMgbm90IHBpY2tpbmcgb25l IG9yIHRoZSBvdGhlciBhcHByb2FjaCwNCj4+ICAgdGhlIHBsYW4gaXMgdGhhdCB0aGUgYXBwcyBh cmVhIHdpbGwgZG8gYW55IHNlbGVjdGlvbg0KPj4gICBuZWVkZWQgYW5kIGZpZ3VyZSBvdXQgdGhl IGJlc3Qgc3RhcnRpbmcgcG9pbnQgZm9yIGENCj4+ICAgc3RhbmRhcmRzLXRyYWNrIFJGQyBvbiB3 ZWIgZGlzY292ZXJ5IGFuZCB3ZSdsbCB1c2UgdGhlaXINCj4+ICAgZmluZSB3b3JrIGZvciBkb2lu ZyBtb3JlIHdpdGggb2F1dGguDQo+DQo+IFRoYW5rIHlvdSBTdGVwaGVuLCBJIHRoaW5rLiAgOi0p DQo+DQo+IFNvIHRoZSBkaXNjdXNzaW9uIG9uIGFwcHMtZGlzY3VzcyBub3cgc2hvdWxkIGJlIGZv Y3VzZWQgb24gd2hpY2ggb2YgdGhlIHR3byBzaG91bGQgYmUgdGhlIGJhc2lzIGZvciBmb3J3YXJk IHByb2dyZXNzLiAgSSd2ZSBwbGFjZWQgYm90aCBkb2N1bWVudHMgaW4gIkNhbGwgZm9yIEFkb3B0 aW9uIiBzdGF0ZSBpbiB0aGUgZGF0YXRyYWNrZXIgZm9yIGFwcHNhd2cuDQo+DQo+IExldCB0aGUg Z2FtZXMgYmVnaW4uDQo+DQo+IC1NU0sNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPiBhcHBzLWRp c2N1c3NAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_4E1F6AAD24975D4BA5B16804296739436648BF09TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pkkga25vdyB0aGF0IDcgb2YgdGhlIDggcHVibGljIHBhcnRpY2lwYW50cyBpbiB0aGUgY3VycmVu dCBPcGVuSUQgQ29ubmVjdCBpbnRlcm9wIHRlc3RpbmcgaGF2ZSBpbXBsZW1lbnRlZCBTV0QgYXQg dGhpcyBwb2ludC4mbmJzcDsgKEkga25vdyBvZiBzZXZlcmFsIG1vcmUgd2hv4oCZdmUNCiBidWls dCBpdCBhcyB3ZWxsIGJ1dCBoYXZlbuKAmXQgY2hvc2VuIHRvIG1ha2UgdGhlaXIgaW50ZXJvcCB0 ZXN0IHJlc3VsdHMgcHVibGljIHlldC4pJm5ic3A7IFRoZXJlIGFyZSBsaWtlbHkgb3RoZXIgaW1w bGVtZW50YXRpb25zIEnigJltIHVuYXdhcmUgb2YuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0g TWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gb2F1dGgtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkJsYWluZSBDb29rPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDE3 LCAyMDEyIDM6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+IFRpbSBCcmF5PGJyPg0KPGI+Q2M6PC9iPiBv YXV0aEBpZXRmLm9yZyBXRzsgYXBwcy1kaXNjdXNzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbT0FVVEgtV0ddIFthcHBzLWRpc2N1c3NdIFdlYiBGaW5nZXIgdnMuIFNpbXBsZSBX ZWIgRGlzY292ZXJ5IChTV0QpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5UaGF0J3MgYSB0cmlja3kgcXVlc3Rpb24g LSBtYXliZSBvbmUgZ29vZ2xlIGNhbiBoZWxwIGFuc3dlcj8gVGhlcmUgYXJlIGEgYnVuY2ggb2Yg cHJvamVjdHMgdXNpbmcgd2ViZmluZ2VyLCBpbmNsdWRpbmcNCjxhIGhyZWY9Imh0dHA6Ly9zdGF0 dXMubmV0Ij5zdGF0dXMubmV0PC9hPiwgb3N0YXR1cyBpbiBnZW5lcmFsLCBkaWFzcG9yYSwgdW5o b3N0ZWQsIGZyZWVkb21ib3goPyksIGFuZCBJJ20gc3VyZSBvdGhlcnMsIGJ1dCBJIGhhdmUgbm8g aWRlYSBob3cgdGhhdCB0cmFuc2xhdGVzIGludG8gYWN0dWFsIHVzZXJzIG9yIHByb2ZpbGVzLjxv OnA+PC9vOnA+PC9wPg0KPHA+R21haWwsIGFvbCwgYW5kIHlhaG9vIGFsbCBwdXQgdXAgd2ViZmlu Z2VyIGVuZHBvaW50cywgYnV0IHRoZXJlIGhhc24ndCBiZWVuIG11Y2ggbW92ZW1lbnQsIEkgdGhp bmsgZHVlIHRvIHRoZSBjaGlja2VuIGFuZCBlZ2cgbmF0dXJlIG9mIGFkb3B0aW9uIGFyb3VuZCBk ZWNlbnRyYWxpemVkIHRvb2xzLjxvOnA+PC9vOnA+PC9wPg0KPHA+Yi48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBcHIgMTcsIDIwMTIgMTE6MTMgQU0sICZx dW90O1RpbSBCcmF5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGJyYXlAdGV4dHVhbGl0eS5j b20iIHRhcmdldD0iX2JsYW5rIj50YnJheUB0ZXh0dWFsaXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBpcyB0aGUgZGVwbG95bWVu dCBzdGF0dXMgb2YgdGhlc2UgdHdvIHNwZWNzPyAmbmJzcDtJcyBlaXRoZXIgZGVwbG95ZWQ8YnI+ DQptdWNoIGF0IGFsbD8gJm5ic3A7LVQ8YnI+DQo8YnI+DQpPbiBGcmksIEFwciAxMywgMjAxMiBh dCAxMDo0NSBBTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1za0Bj bG91ZG1hcmsuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNrQGNsb3VkbWFyay5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsm Z3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFN0 ZXBoZW4gRmFycmVsbDxicj4NCiZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgQXByaWwgMTMsIDIwMTIg OToyMyBBTTxicj4NCiZndDsmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4gV0c8YnI+DQomZ3Q7Jmd0OyBDYzog QXBwcyBEaXNjdXNzPGJyPg0KJmd0OyZndDsgU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFtP QVVUSC1XR10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdlYiBEaXNjb3ZlcnkgKFNXRCk8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNvIEhhbm5lcyBhbmQgRGVyZWsgYW5kIEkgaGF2ZSBiZWVu IGRpc2N1c3NpbmcgdGhpcyB3aXRoIHRoZSBBcHBzIEFEczxicj4NCiZndDsmZ3Q7IGFuZCBBcHBz LWFyZWEgV0cgY2hhaXJzLiBJJ3ZlIGFsc28gcmVhZCB0aGUgZG9jcyBub3csIGFuZCBhZnRlciBh bGw8YnI+DQomZ3Q7Jmd0OyB0aGF0IHdlJ3ZlIGRlY2lkZWQgdGhhdCB0aGlzIHRvcGljICh3aGF0 IHRvIGRvIHdpdGggc3dkIGFuZCB3ZWJmaW5nZXIpPGJyPg0KJmd0OyZndDsgaXMgYmVzdCBoYW5k bGVkIGluIHRoZSBhcHBzIGFyZWEgYW5kIG5vdCBpbiB0aGUgb2F1dGggV0cuPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBUaGUgbG9naWMgZm9yIHRoYXQgaXMgdGhhdCAxKSB0aGUgdHdvIHBy b3Bvc2FscyBhcmUgZG9pbmcgdGhlIHNhbWU8YnI+DQomZ3Q7Jmd0OyB0aGluZyBhbmQgd2UgZG9u J3Qgd2FudCB0d28gZGlmZmVyZW50IHN0YW5kYXJkcyBmb3IgdGhhdCwgYikgdGhpcyBpczxicj4N CiZndDsmZ3Q7IG5vdCBhbiBvYXV0aC1zcGVjaWZpYyB0aGluZyBub3IgaXMgaXQgYSBnZW5lcmFs IHNlY3VyaXR5IHRoaW5nLCBhbmQgYyk8YnI+DQomZ3Q7Jmd0OyB0aGVyZSBpcyBjbGVhcmx5IGFs cmVhZHkgaW50ZXJlc3QgaW4gdGhlIHRvcGljIGluIHRoZSBhcHBzIGFyZWEgc28gaXRzPGJyPg0K Jmd0OyZndDsgcmVhc29uYWJsZSBmb3IgdGhlIG9hdXRoIHdnIHRvIHVzZSB0aGF0IHdoZW4gaXRz IHJlYWR5Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIGFwcHNhd2cgY2hhaXJzIGFu ZCBhcHBzIEFEcyBhcmUgb2sgd2l0aCB0aGUgd29yayBiZWluZyBkb25lIHRoZXJlLjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgU286LTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLSBJ J3ZlIGFza2VkIHRoZSBvYXV0aCBjaGFpcnMgdG8gdGFrZSBkb2luZyB3b3JrIG9uIHN3ZDxicj4N CiZndDsmZ3Q7ICZuYnNwOyBvdXQgb2YgdGhlIHByb3Bvc2VkIG5ldyBjaGFydGVyPGJyPg0KJmd0 OyZndDsgLSBJdCBtYXkgYmUgdGhhdCB5b3Ugd2FudCB0byBhZGQgc29tZXRoaW5nIHNheWluZyB0 aGF0PGJyPg0KJmd0OyZndDsgJm5ic3A7IG9hdXRoIHdpbGwgdXNlIHRoZSByZXN1bHRzIG9mIHdv cmsgaW4gdGhlIGFwcGxpY2F0aW9uczxicj4NCiZndDsmZ3Q7ICZuYnNwOyBhcmVhIG9uIGEgd2Vi IGRpc2NvdmVyeSBwcm90b2NvbCBhcyBhIGJhc2lzIGZvciBkb2luZzxicj4NCiZndDsmZ3Q7ICZu YnNwOyB0aGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIHdvcmsgaGVyZTxicj4NCiZndDsm Z3Q7IC0gRGlzY3Vzc2lvbiBvZiB3ZWJmaW5nZXIgYW5kIHN3ZCBzaG91bGQgbW92ZSBvdmVyIHRv PGJyPg0KJmd0OyZndDsgJm5ic3A7IHRoZSBhcHBzLWRpc2N1c3MgbGlzdDxicj4NCiZndDsmZ3Q7 IC0gTm90ZTogdGhpcyBpcyBub3QgcGlja2luZyBvbmUgb3IgdGhlIG90aGVyIGFwcHJvYWNoLDxi cj4NCiZndDsmZ3Q7ICZuYnNwOyB0aGUgcGxhbiBpcyB0aGF0IHRoZSBhcHBzIGFyZWEgd2lsbCBk byBhbnkgc2VsZWN0aW9uPGJyPg0KJmd0OyZndDsgJm5ic3A7IG5lZWRlZCBhbmQgZmlndXJlIG91 dCB0aGUgYmVzdCBzdGFydGluZyBwb2ludCBmb3IgYTxicj4NCiZndDsmZ3Q7ICZuYnNwOyBzdGFu ZGFyZHMtdHJhY2sgUkZDIG9uIHdlYiBkaXNjb3ZlcnkgYW5kIHdlJ2xsIHVzZSB0aGVpcjxicj4N CiZndDsmZ3Q7ICZuYnNwOyBmaW5lIHdvcmsgZm9yIGRvaW5nIG1vcmUgd2l0aCBvYXV0aC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBUaGFuayB5b3UgU3RlcGhlbiwgSSB0aGluay4gJm5ic3A7Oi0pPGJy Pg0KJmd0Ozxicj4NCiZndDsgU28gdGhlIGRpc2N1c3Npb24gb24gYXBwcy1kaXNjdXNzIG5vdyBz aG91bGQgYmUgZm9jdXNlZCBvbiB3aGljaCBvZiB0aGUgdHdvIHNob3VsZCBiZSB0aGUgYmFzaXMg Zm9yIGZvcndhcmQgcHJvZ3Jlc3MuICZuYnNwO0kndmUgcGxhY2VkIGJvdGggZG9jdW1lbnRzIGlu ICZxdW90O0NhbGwgZm9yIEFkb3B0aW9uJnF1b3Q7IHN0YXRlIGluIHRoZSBkYXRhdHJhY2tlciBm b3IgYXBwc2F3Zy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBMZXQgdGhlIGdhbWVzIGJlZ2luLjxicj4N CiZndDs8YnI+DQomZ3Q7IC1NU0s8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBhcHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vz czwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739436648BF09TK5EX14MBXC284r_-- From msk@cloudmark.com Tue Apr 17 19:54:43 2012 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 93F6011E807F for ; Tue, 17 Apr 2012 19:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRBGFpO7g2pV for ; Tue, 17 Apr 2012 19:54:39 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2183521F85A4 for ; Tue, 17 Apr 2012 19:54:39 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id zEue1i0040ZaKgw01Euexa; Tue, 17 Apr 2012 19:54:38 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=W866pGqk c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=lDLtzceVzjAA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=ddoUimErAAAA:8 a=ZEAgVxdcAAAA:8 a=b6nfwRhkAAAA:8 a=1ZBiGvamRsUXxnLyL2kA:9 a=CVBWwWt7turbtGh4t-YA:7 a=QEXdDO2ut3YA:10 a=BBlAGKNQKQ8A:10 a=lZB815dzVvQA:10 a=vZh6zi8dUYkA:10 a=RjwTPiaSbNEA:10 a=tY9HFf9YrrEDV8tA:21 a=k5p_6fHFk3q7xyLL:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=TPcEOfShVUlMIZ-73esA:9 a=1CAOaISUg5l0VpXdldcA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A:10 a=7a9aNFanojMA:10 a=bpq86B7CLB8A:10 a=H8hBHuawGkQC9Srw:21 a=uTN2_nFSy-wcBptt:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 17 Apr 2012 19:54:38 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHPFR3vuAzKShOkysr2w3xgHGFZaf4OeQ Date: Wed, 18 Apr 2012 02:54:37 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280F707F@exch-mbx901.corp.cloudmark.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B16804296739436648BF09@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436648BF09@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280F707Fexchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334717678; bh=Of8bgNxVwYWEKL7WNcgHTdKOaxX4TXic50dZpF/Rudw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=QjokM1ArmSnycrvew+2H1rvjMRGqUxoDQ5AAlaOCHSfDfsSz7zUwj3Sh8Me6i16Ax GNDVH+z0BWHrRCd5G4ZHpgix2d+bf1iPFH/LR0HUsiVIP6mmQAje9clEVfRkLZxLY/ UmL4vlJuZn2yziWwEK0PPxJxy9aU/cbHz1KZX9zU= Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Wed, 18 Apr 2012 02:54:43 -0000 --_000_9452079D1A51524AA5749AD23E0039280F707Fexchmbx901corpclo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gdGhlcmUgYXJlIHNvbWUgb2YgYm90aC4gIEhvdyB0cmVhY2hlcm91cyBpcyB0aGUgbWlncmF0 aW9uIHBhdGggZnJvbSBTV0QgdG8gV2ViRmluZ2VyLCBmb3IgZXhhbXBsZSwgaW4gY2FzZSBjb25z ZW5zdXMgaXMgdG8gZGV2ZWxvcCBhbmQgbW92ZSBmb3J3YXJkIHdpdGggdGhlIGxhdHRlcj8NCg0K LU1TSw0KDQpGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMt ZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDog VHVlc2RheSwgQXByaWwgMTcsIDIwMTIgNDoyNSBQTQ0KVG86IEJsYWluZSBDb29rOyBUaW0gQnJh eQ0KQ2M6IG9hdXRoQGlldGYub3JnIFdHOyBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbYXBwcy1kaXNjdXNzXSBbT0FVVEgtV0ddIFdlYiBGaW5nZXIgdnMuIFNpbXBsZSBXZWIg RGlzY292ZXJ5IChTV0QpDQoNCkkga25vdyB0aGF0IDcgb2YgdGhlIDggcHVibGljIHBhcnRpY2lw YW50cyBpbiB0aGUgY3VycmVudCBPcGVuSUQgQ29ubmVjdCBpbnRlcm9wIHRlc3RpbmcgaGF2ZSBp bXBsZW1lbnRlZCBTV0QgYXQgdGhpcyBwb2ludC4gIChJIGtub3cgb2Ygc2V2ZXJhbCBtb3JlIHdo b+KAmXZlIGJ1aWx0IGl0IGFzIHdlbGwgYnV0IGhhdmVu4oCZdCBjaG9zZW4gdG8gbWFrZSB0aGVp ciBpbnRlcm9wIHRlc3QgcmVzdWx0cyBwdWJsaWMgeWV0LikgIFRoZXJlIGFyZSBsaWtlbHkgb3Ro ZXIgaW1wbGVtZW50YXRpb25zIEnigJltIHVuYXdhcmUgb2YuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJv bTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4g W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmxhaW5lIENvb2sN ClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAyMDEyIDM6NTQgUE0NClRvOiBUaW0gQnJheQ0KQ2M6 IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gV0c7IGFwcHMtZGlzY3Vzc0Bp ZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gW2FwcHMtZGlzY3Vzc10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdlYiBEaXNjb3Zlcnkg KFNXRCkNCg0KDQpUaGF0J3MgYSB0cmlja3kgcXVlc3Rpb24gLSBtYXliZSBvbmUgZ29vZ2xlIGNh biBoZWxwIGFuc3dlcj8gVGhlcmUgYXJlIGEgYnVuY2ggb2YgcHJvamVjdHMgdXNpbmcgd2ViZmlu Z2VyLCBpbmNsdWRpbmcgc3RhdHVzLm5ldDxodHRwOi8vc3RhdHVzLm5ldD4sIG9zdGF0dXMgaW4g Z2VuZXJhbCwgZGlhc3BvcmEsIHVuaG9zdGVkLCBmcmVlZG9tYm94KD8pLCBhbmQgSSdtIHN1cmUg b3RoZXJzLCBidXQgSSBoYXZlIG5vIGlkZWEgaG93IHRoYXQgdHJhbnNsYXRlcyBpbnRvIGFjdHVh bCB1c2VycyBvciBwcm9maWxlcy4NCg0KR21haWwsIGFvbCwgYW5kIHlhaG9vIGFsbCBwdXQgdXAg d2ViZmluZ2VyIGVuZHBvaW50cywgYnV0IHRoZXJlIGhhc24ndCBiZWVuIG11Y2ggbW92ZW1lbnQs IEkgdGhpbmsgZHVlIHRvIHRoZSBjaGlja2VuIGFuZCBlZ2cgbmF0dXJlIG9mIGFkb3B0aW9uIGFy b3VuZCBkZWNlbnRyYWxpemVkIHRvb2xzLg0KDQpiLg0KT24gQXByIDE3LCAyMDEyIDExOjEzIEFN LCAiVGltIEJyYXkiIDx0YnJheUB0ZXh0dWFsaXR5LmNvbTxtYWlsdG86dGJyYXlAdGV4dHVhbGl0 eS5jb20+PiB3cm90ZToNCldoYXQgaXMgdGhlIGRlcGxveW1lbnQgc3RhdHVzIG9mIHRoZXNlIHR3 byBzcGVjcz8gIElzIGVpdGhlciBkZXBsb3llZA0KbXVjaCBhdCBhbGw/ICAtVA0KDQpPbiBGcmks IEFwciAxMywgMjAxMiBhdCAxMDo0NSBBTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSA8bXNrQGNsb3Vk bWFyay5jb208bWFpbHRvOm1za0BjbG91ZG1hcmsuY29tPj4gd3JvdGU6DQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmFwcHMtZGlzY3Vz cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNCj4+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTMs IDIwMTIgOToyMyBBTQ0KPj4gVG86IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz4gV0cNCj4+IENjOiBBcHBzIERpc2N1c3MNCj4+IFN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNz XSBbT0FVVEgtV0ddIFdlYiBGaW5nZXIgdnMuIFNpbXBsZSBXZWIgRGlzY292ZXJ5IChTV0QpDQo+ Pg0KPj4gU28gSGFubmVzIGFuZCBEZXJlayBhbmQgSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB0aGlz IHdpdGggdGhlIEFwcHMgQURzDQo+PiBhbmQgQXBwcy1hcmVhIFdHIGNoYWlycy4gSSd2ZSBhbHNv IHJlYWQgdGhlIGRvY3Mgbm93LCBhbmQgYWZ0ZXIgYWxsDQo+PiB0aGF0IHdlJ3ZlIGRlY2lkZWQg dGhhdCB0aGlzIHRvcGljICh3aGF0IHRvIGRvIHdpdGggc3dkIGFuZCB3ZWJmaW5nZXIpDQo+PiBp cyBiZXN0IGhhbmRsZWQgaW4gdGhlIGFwcHMgYXJlYSBhbmQgbm90IGluIHRoZSBvYXV0aCBXRy4N Cj4+DQo+PiBUaGUgbG9naWMgZm9yIHRoYXQgaXMgdGhhdCAxKSB0aGUgdHdvIHByb3Bvc2FscyBh cmUgZG9pbmcgdGhlIHNhbWUNCj4+IHRoaW5nIGFuZCB3ZSBkb24ndCB3YW50IHR3byBkaWZmZXJl bnQgc3RhbmRhcmRzIGZvciB0aGF0LCBiKSB0aGlzIGlzDQo+PiBub3QgYW4gb2F1dGgtc3BlY2lm aWMgdGhpbmcgbm9yIGlzIGl0IGEgZ2VuZXJhbCBzZWN1cml0eSB0aGluZywgYW5kIGMpDQo+PiB0 aGVyZSBpcyBjbGVhcmx5IGFscmVhZHkgaW50ZXJlc3QgaW4gdGhlIHRvcGljIGluIHRoZSBhcHBz IGFyZWEgc28gaXRzDQo+PiByZWFzb25hYmxlIGZvciB0aGUgb2F1dGggd2cgdG8gdXNlIHRoYXQg d2hlbiBpdHMgcmVhZHkuDQo+Pg0KPj4gVGhlIGFwcHNhd2cgY2hhaXJzIGFuZCBhcHBzIEFEcyBh cmUgb2sgd2l0aCB0aGUgd29yayBiZWluZyBkb25lIHRoZXJlLg0KPj4NCj4+IFNvOi0NCj4+DQo+ PiAtIEkndmUgYXNrZWQgdGhlIG9hdXRoIGNoYWlycyB0byB0YWtlIGRvaW5nIHdvcmsgb24gc3dk DQo+PiAgIG91dCBvZiB0aGUgcHJvcG9zZWQgbmV3IGNoYXJ0ZXINCj4+IC0gSXQgbWF5IGJlIHRo YXQgeW91IHdhbnQgdG8gYWRkIHNvbWV0aGluZyBzYXlpbmcgdGhhdA0KPj4gICBvYXV0aCB3aWxs IHVzZSB0aGUgcmVzdWx0cyBvZiB3b3JrIGluIHRoZSBhcHBsaWNhdGlvbnMNCj4+ICAgYXJlYSBv biBhIHdlYiBkaXNjb3ZlcnkgcHJvdG9jb2wgYXMgYSBiYXNpcyBmb3IgZG9pbmcNCj4+ICAgdGhl IGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiB3b3JrIGhlcmUNCj4+IC0gRGlzY3Vzc2lvbiBv ZiB3ZWJmaW5nZXIgYW5kIHN3ZCBzaG91bGQgbW92ZSBvdmVyIHRvDQo+PiAgIHRoZSBhcHBzLWRp c2N1c3MgbGlzdA0KPj4gLSBOb3RlOiB0aGlzIGlzIG5vdCBwaWNraW5nIG9uZSBvciB0aGUgb3Ro ZXIgYXBwcm9hY2gsDQo+PiAgIHRoZSBwbGFuIGlzIHRoYXQgdGhlIGFwcHMgYXJlYSB3aWxsIGRv IGFueSBzZWxlY3Rpb24NCj4+ICAgbmVlZGVkIGFuZCBmaWd1cmUgb3V0IHRoZSBiZXN0IHN0YXJ0 aW5nIHBvaW50IGZvciBhDQo+PiAgIHN0YW5kYXJkcy10cmFjayBSRkMgb24gd2ViIGRpc2NvdmVy eSBhbmQgd2UnbGwgdXNlIHRoZWlyDQo+PiAgIGZpbmUgd29yayBmb3IgZG9pbmcgbW9yZSB3aXRo IG9hdXRoLg0KPg0KPiBUaGFuayB5b3UgU3RlcGhlbiwgSSB0aGluay4gIDotKQ0KPg0KPiBTbyB0 aGUgZGlzY3Vzc2lvbiBvbiBhcHBzLWRpc2N1c3Mgbm93IHNob3VsZCBiZSBmb2N1c2VkIG9uIHdo aWNoIG9mIHRoZSB0d28gc2hvdWxkIGJlIHRoZSBiYXNpcyBmb3IgZm9yd2FyZCBwcm9ncmVzcy4g IEkndmUgcGxhY2VkIGJvdGggZG9jdW1lbnRzIGluICJDYWxsIGZvciBBZG9wdGlvbiIgc3RhdGUg aW4gdGhlIGRhdGF0cmFja2VyIGZvciBhcHBzYXdnLg0KPg0KPiBMZXQgdGhlIGdhbWVzIGJlZ2lu Lg0KPg0KPiAtTVNLDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IGFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCj4gYXBwcy1kaXNjdXNzQGlldGYu b3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQo= --_000_9452079D1A51524AA5749AD23E0039280F707Fexchmbx901corpclo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TbyB0aGVyZSBhcmUgc29tZSBvZiBib3RoLiZuYnNwOyBIb3cgdHJlYWNoZXJv dXMgaXMgdGhlIG1pZ3JhdGlvbiBwYXRoIGZyb20gU1dEIHRvIFdlYkZpbmdlciwgZm9yIGV4YW1w bGUsIGluIGNhc2UgY29uc2Vuc3VzIGlzIHRvIGRldmVsb3AgYW5kIG1vdmUgZm9yd2FyZCB3aXRo DQogdGhlIGxhdHRlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1NU0s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzph cHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBK b25lczxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiA0OjI1IFBNPGJy Pg0KPGI+VG86PC9iPiBCbGFpbmUgQ29vazsgVGltIEJyYXk8YnI+DQo8Yj5DYzo8L2I+IG9hdXRo QGlldGYub3JnIFdHOyBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFthcHBzLWRpc2N1c3NdIFtPQVVUSC1XR10gV2ViIEZpbmdlciB2cy4gU2ltcGxlIFdlYiBE aXNjb3ZlcnkgKFNXRCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBrbm93IHRo YXQgNyBvZiB0aGUgOCBwdWJsaWMgcGFydGljaXBhbnRzIGluIHRoZSBjdXJyZW50IE9wZW5JRCBD b25uZWN0IGludGVyb3AgdGVzdGluZyBoYXZlIGltcGxlbWVudGVkIFNXRCBhdCB0aGlzIHBvaW50 LiZuYnNwOyAoSSBrbm93IG9mIHNldmVyYWwgbW9yZSB3aG/igJl2ZQ0KIGJ1aWx0IGl0IGFzIHdl bGwgYnV0IGhhdmVu4oCZdCBjaG9zZW4gdG8gbWFrZSB0aGVpciBpbnRlcm9wIHRlc3QgcmVzdWx0 cyBwdWJsaWMgeWV0LikmbmJzcDsgVGhlcmUgYXJlIGxpa2VseSBvdGhlciBpbXBsZW1lbnRhdGlv bnMgSeKAmW0gdW5hd2FyZSBvZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVm PSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CbGFpbmUgQ29vazxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBBcHJpbCAxNywgMjAxMiAzOjU0IFBNPGJyPg0KPGI+VG86PC9iPiBUaW0g QnJheTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0 aEBpZXRmLm9yZzwvYT4gV0c7IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmci Pg0KYXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBbYXBwcy1kaXNjdXNzXSBXZWIgRmluZ2VyIHZzLiBTaW1wbGUgV2ViIERpc2NvdmVy eSAoU1dEKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHA+VGhhdCdzIGEgdHJpY2t5IHF1ZXN0aW9uIC0gbWF5YmUgb25l IGdvb2dsZSBjYW4gaGVscCBhbnN3ZXI/IFRoZXJlIGFyZSBhIGJ1bmNoIG9mIHByb2plY3RzIHVz aW5nIHdlYmZpbmdlciwgaW5jbHVkaW5nDQo8YSBocmVmPSJodHRwOi8vc3RhdHVzLm5ldCI+c3Rh dHVzLm5ldDwvYT4sIG9zdGF0dXMgaW4gZ2VuZXJhbCwgZGlhc3BvcmEsIHVuaG9zdGVkLCBmcmVl ZG9tYm94KD8pLCBhbmQgSSdtIHN1cmUgb3RoZXJzLCBidXQgSSBoYXZlIG5vIGlkZWEgaG93IHRo YXQgdHJhbnNsYXRlcyBpbnRvIGFjdHVhbCB1c2VycyBvciBwcm9maWxlcy48bzpwPjwvbzpwPjwv cD4NCjxwPkdtYWlsLCBhb2wsIGFuZCB5YWhvbyBhbGwgcHV0IHVwIHdlYmZpbmdlciBlbmRwb2lu dHMsIGJ1dCB0aGVyZSBoYXNuJ3QgYmVlbiBtdWNoIG1vdmVtZW50LCBJIHRoaW5rIGR1ZSB0byB0 aGUgY2hpY2tlbiBhbmQgZWdnIG5hdHVyZSBvZiBhZG9wdGlvbiBhcm91bmQgZGVjZW50cmFsaXpl ZCB0b29scy48bzpwPjwvbzpwPjwvcD4NCjxwPmIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gQXByIDE3LCAyMDEyIDExOjEzIEFNLCAmcXVvdDtUaW0gQnJh eSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tIiB0YXJnZXQ9 Il9ibGFuayI+dGJyYXlAdGV4dHVhbGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgaXMgdGhlIGRlcGxveW1lbnQgc3RhdHVzIG9m IHRoZXNlIHR3byBzcGVjcz8gJm5ic3A7SXMgZWl0aGVyIGRlcGxveWVkPGJyPg0KbXVjaCBhdCBh bGw/ICZuYnNwOy1UPGJyPg0KPGJyPg0KT24gRnJpLCBBcHIgMTMsIDIwMTIgYXQgMTA6NDUgQU0s IE11cnJheSBTLiBLdWNoZXJhd3kgJmx0OzxhIGhyZWY9Im1haWx0bzptc2tAY2xvdWRtYXJrLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1za0BjbG91ZG1hcmsuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiA8 YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5hcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJt YWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hcHBz LWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJl bGw8YnI+DQomZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEFwcmlsIDEzLCAyMDEyIDk6MjMgQU08YnI+ DQomZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+IFdHPGJyPg0KJmd0OyZndDsgQ2M6IEFwcHMgRGlzY3Vz czxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBbT0FVVEgtV0ddIFdl YiBGaW5nZXIgdnMuIFNpbXBsZSBXZWIgRGlzY292ZXJ5IChTV0QpPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBTbyBIYW5uZXMgYW5kIERlcmVrIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5n IHRoaXMgd2l0aCB0aGUgQXBwcyBBRHM8YnI+DQomZ3Q7Jmd0OyBhbmQgQXBwcy1hcmVhIFdHIGNo YWlycy4gSSd2ZSBhbHNvIHJlYWQgdGhlIGRvY3Mgbm93LCBhbmQgYWZ0ZXIgYWxsPGJyPg0KJmd0 OyZndDsgdGhhdCB3ZSd2ZSBkZWNpZGVkIHRoYXQgdGhpcyB0b3BpYyAod2hhdCB0byBkbyB3aXRo IHN3ZCBhbmQgd2ViZmluZ2VyKTxicj4NCiZndDsmZ3Q7IGlzIGJlc3QgaGFuZGxlZCBpbiB0aGUg YXBwcyBhcmVhIGFuZCBub3QgaW4gdGhlIG9hdXRoIFdHLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgVGhlIGxvZ2ljIGZvciB0aGF0IGlzIHRoYXQgMSkgdGhlIHR3byBwcm9wb3NhbHMgYXJl IGRvaW5nIHRoZSBzYW1lPGJyPg0KJmd0OyZndDsgdGhpbmcgYW5kIHdlIGRvbid0IHdhbnQgdHdv IGRpZmZlcmVudCBzdGFuZGFyZHMgZm9yIHRoYXQsIGIpIHRoaXMgaXM8YnI+DQomZ3Q7Jmd0OyBu b3QgYW4gb2F1dGgtc3BlY2lmaWMgdGhpbmcgbm9yIGlzIGl0IGEgZ2VuZXJhbCBzZWN1cml0eSB0 aGluZywgYW5kIGMpPGJyPg0KJmd0OyZndDsgdGhlcmUgaXMgY2xlYXJseSBhbHJlYWR5IGludGVy ZXN0IGluIHRoZSB0b3BpYyBpbiB0aGUgYXBwcyBhcmVhIHNvIGl0czxicj4NCiZndDsmZ3Q7IHJl YXNvbmFibGUgZm9yIHRoZSBvYXV0aCB3ZyB0byB1c2UgdGhhdCB3aGVuIGl0cyByZWFkeS48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBhcHBzYXdnIGNoYWlycyBhbmQgYXBwcyBBRHMg YXJlIG9rIHdpdGggdGhlIHdvcmsgYmVpbmcgZG9uZSB0aGVyZS48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFNvOi08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0gSSd2ZSBhc2tlZCB0 aGUgb2F1dGggY2hhaXJzIHRvIHRha2UgZG9pbmcgd29yayBvbiBzd2Q8YnI+DQomZ3Q7Jmd0OyAm bmJzcDsgb3V0IG9mIHRoZSBwcm9wb3NlZCBuZXcgY2hhcnRlcjxicj4NCiZndDsmZ3Q7IC0gSXQg bWF5IGJlIHRoYXQgeW91IHdhbnQgdG8gYWRkIHNvbWV0aGluZyBzYXlpbmcgdGhhdDxicj4NCiZn dDsmZ3Q7ICZuYnNwOyBvYXV0aCB3aWxsIHVzZSB0aGUgcmVzdWx0cyBvZiB3b3JrIGluIHRoZSBh cHBsaWNhdGlvbnM8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgYXJlYSBvbiBhIHdlYiBkaXNjb3Zlcnkg cHJvdG9jb2wgYXMgYSBiYXNpcyBmb3IgZG9pbmc8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgdGhlIGR5 bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiB3b3JrIGhlcmU8YnI+DQomZ3Q7Jmd0OyAtIERpc2N1 c3Npb24gb2Ygd2ViZmluZ2VyIGFuZCBzd2Qgc2hvdWxkIG1vdmUgb3ZlciB0bzxicj4NCiZndDsm Z3Q7ICZuYnNwOyB0aGUgYXBwcy1kaXNjdXNzIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAtIE5vdGU6IHRo aXMgaXMgbm90IHBpY2tpbmcgb25lIG9yIHRoZSBvdGhlciBhcHByb2FjaCw8YnI+DQomZ3Q7Jmd0 OyAmbmJzcDsgdGhlIHBsYW4gaXMgdGhhdCB0aGUgYXBwcyBhcmVhIHdpbGwgZG8gYW55IHNlbGVj dGlvbjxicj4NCiZndDsmZ3Q7ICZuYnNwOyBuZWVkZWQgYW5kIGZpZ3VyZSBvdXQgdGhlIGJlc3Qg c3RhcnRpbmcgcG9pbnQgZm9yIGE8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgc3RhbmRhcmRzLXRyYWNr IFJGQyBvbiB3ZWIgZGlzY292ZXJ5IGFuZCB3ZSdsbCB1c2UgdGhlaXI8YnI+DQomZ3Q7Jmd0OyAm bmJzcDsgZmluZSB3b3JrIGZvciBkb2luZyBtb3JlIHdpdGggb2F1dGguPGJyPg0KJmd0Ozxicj4N CiZndDsgVGhhbmsgeW91IFN0ZXBoZW4sIEkgdGhpbmsuICZuYnNwOzotKTxicj4NCiZndDs8YnI+ DQomZ3Q7IFNvIHRoZSBkaXNjdXNzaW9uIG9uIGFwcHMtZGlzY3VzcyBub3cgc2hvdWxkIGJlIGZv Y3VzZWQgb24gd2hpY2ggb2YgdGhlIHR3byBzaG91bGQgYmUgdGhlIGJhc2lzIGZvciBmb3J3YXJk IHByb2dyZXNzLiAmbmJzcDtJJ3ZlIHBsYWNlZCBib3RoIGRvY3VtZW50cyBpbiAmcXVvdDtDYWxs IGZvciBBZG9wdGlvbiZxdW90OyBzdGF0ZSBpbiB0aGUgZGF0YXRyYWNrZXIgZm9yIGFwcHNhd2cu PGJyPg0KJmd0Ozxicj4NCiZndDsgTGV0IHRoZSBnYW1lcyBiZWdpbi48YnI+DQomZ3Q7PGJyPg0K Jmd0OyAtTVNLPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsgYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdDxicj4NCiZndDsg PGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFw cHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3M8L2E+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9452079D1A51524AA5749AD23E0039280F707Fexchmbx901corpclo_-- From torsten@lodderstedt.net Wed Apr 18 12:43:31 2012 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 EA3AD21F854F for ; Wed, 18 Apr 2012 12:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsaJI7x2ZZez for ; Wed, 18 Apr 2012 12:43:28 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by ietfa.amsl.com (Postfix) with ESMTP id D73CA21F8532 for ; Wed, 18 Apr 2012 12:43:27 -0700 (PDT) Received: from [79.253.18.109] (helo=[192.168.71.36]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SKamk-0008RE-1G; Wed, 18 Apr 2012 21:43:26 +0200 Message-ID: <4F8F1960.50308@lodderstedt.net> Date: Wed, 18 Apr 2012 21:43:28 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> In-Reply-To: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] IIW and OAuth 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: Wed, 18 Apr 2012 19:43:32 -0000 I will be there until Thursday evening, so I would prefer Tuesday or Wednesday evening. regards, Torsten. Am 16.04.2012 13:55, schrieb Hannes Tschofenig: > Hi guys, > > I was wondering how many of you will be at the upcoming IIW in Mountain View (or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd). > > I thought it might be good to useful to get together on the Friday after the IIW event for a OAuth breakfast chat. > I am sure that there are still a couple of topics that require brainstorming. > > Drop me a message if you are able and interested. > > Ciao > Hannes > > PS: Please do not forget to read the Assertion specs so that we can get them out of the door. > (And thanks to those who have already read them.) > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Wed Apr 18 12:49:38 2012 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 219F721F8532 for ; Wed, 18 Apr 2012 12:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBnojUh-vLdk for ; Wed, 18 Apr 2012 12:49:34 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by ietfa.amsl.com (Postfix) with ESMTP id DF08C21F84D3 for ; Wed, 18 Apr 2012 12:49:33 -0700 (PDT) Received: from [79.253.18.109] (helo=[192.168.71.36]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SKase-0000Pj-4a; Wed, 18 Apr 2012 21:49:32 +0200 Message-ID: <4F8F1ACE.4030407@lodderstedt.net> Date: Wed, 18 Apr 2012 21:49:34 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Eran Hammer References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F47@P3PWEX2MB008.ex2.secureserver.net> <6760C38E-7C0C-412F-A285-8F4CB2858F30@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE92E4@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FE92E4@P3PWEX2MB008.ex2.secureserver.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration 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: Wed, 18 Apr 2012 19:49:38 -0000 Hi Eran, why do you see a relationship between dynamic client registration and discovery? Basically, we don't care so far how a client finds tokens and end-user authorization point. Why is this any different for the client registration endpoint (or the revocation endpoint)? Or do you have a bigger picture in mind? regards, Torsten. Am 15.04.2012 22:36, schrieb Eran Hammer: > Where did I say I'm not interested in this work?! > > All I was saying is that it would be better to postpone it until the discovery layer, which this draft clearly relies upon, is a bit clearer. I would be satisfied with a simple note stating that if the discovery work at the APP area isn't complete, the WG may choose to delay work on this document until ready. > > EH > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Sunday, April 15, 2012 9:01 AM >> To: Eran Hammer >> Cc: Hannes Tschofenig; oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Dynamic Client Registration >> >> Hi Eran, >> >> you are saying that you are not interested in the dynamic client registration >> work and that's OK. There are, however, a couple of other folks in the group >> who had expressed interest to work on it, to review and to implement it. >> >> Note also that the discovery and the dynamic client registration is different >> from each other; there is a relationship but they are nevertheless different. >> >> Ciao >> Hannes >> >> PS: Moving the Simple Web Discovery to the Apps area working group does >> not mean that it will not be done. On the contrary there will be work happing >> and we are just trying to figure out what the difference between SWD and >> WebFinger is. >> >> On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote: >> >>> I'd like to see 'Dynamic Client Registration' removed from the charter along >> with SWD for the sole reason that figuring out a generic discovery mechanism >> is going to take some time and this WG has enough other work to focus on >> while that happens elsewhere. I expect this to come back in the next round >> with much more deployment experience and discovery clarity. >>> EH >>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Hannes Tschofenig >>>> Sent: Friday, April 13, 2012 7:36 AM >>>> To: oauth@ietf.org WG >>>> Subject: [OAUTH-WG] Dynamic Client Registration >>>> >>>> Hi all, >>>> >>>> at the IETF#83 OAuth working group meeting we had some confusion >>>> about the Dynamic Client Registration and the Simple Web Discovery >>>> item. I just listened to the audio recording again. >>>> >>>> With the ongoing mailing list discussion regarding WebFinger vs. >>>> Simple Web Discovery I hope that folks had a chance to look at the >>>> documents again and so the confusion of some got resolved. >>>> >>>> I believe the proposed new charter item is sufficiently clear with >>>> regard to the scope of the work. Right? >>>> Here is the item again: >>>> " >>>> Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the >>>> IESG for consideration as a Proposed Standard >>>> >>>> [Starting point for the work will be >>>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg >>>> ] >>>> " >>>> >>>> Of course there there is a relationship between Simple Web Discovery >>>> (or >>>> WebFinger) and the dynamic client registration since the client first >>>> needs to discover the client registration endpoint at the >>>> authorization server before interacting with it. >>>> >>>> Now, one thing that just came to my mind when looking again at draft- >>>> hardjono-oauth-dynreq was the following: Could the Client >>>> Registration Request and Response protocol exchange could become a >>>> profile of the SCIM protocol? In some sense this exchange is nothing >>>> else than provisioning an account at the Authorization Server (along with >> some meta-data). >>>> Is this too far fetched? >>>> >>>> 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 From eran@hueniverse.com Wed Apr 18 12:51:17 2012 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 5E94511E8089 for ; Wed, 18 Apr 2012 12:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Aq09aKWihpM for ; Wed, 18 Apr 2012 12:51:15 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id BF74321F84FF for ; Wed, 18 Apr 2012 12:51:13 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id zXrD1i0010EuLVk01XrDAv; Wed, 18 Apr 2012 12:51:13 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Wed, 18 Apr 2012 12:51:12 -0700 From: Eran Hammer To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Dynamic Client Registration Thread-Index: AQHNGYLIAhnVBxyYNEuwmb5Seq6ic5abalPQgAEZ9wD//9bm0IAFH+QA//+LAjA= Date: Wed, 18 Apr 2012 19:51:11 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFCD2@P3PWEX2MB008.ex2.secureserver.net> References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F47@P3PWEX2MB008.ex2.secureserver.net> <6760C38E-7C0C-412F-A285-8F4CB2858F30@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE92E4@P3PWEX2MB008.ex2.secureserver.net> <4F8F1ACE.4030407@lodderstedt.net> In-Reply-To: <4F8F1ACE.4030407@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [63.79.89.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration 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: Wed, 18 Apr 2012 19:51:17 -0000 Because it is in the draft the WG is suppose to consider. It's a stated dep= endency. EH > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Wednesday, April 18, 2012 12:50 PM > To: Eran Hammer > Cc: Hannes Tschofenig; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Dynamic Client Registration >=20 > Hi Eran, >=20 > why do you see a relationship between dynamic client registration and > discovery? Basically, we don't care so far how a client finds tokens and = end- > user authorization point. Why is this any different for the client regist= ration > endpoint (or the revocation endpoint)? Or do you have a bigger picture in > mind? >=20 > regards, > Torsten. >=20 > Am 15.04.2012 22:36, schrieb Eran Hammer: > > Where did I say I'm not interested in this work?! > > > > All I was saying is that it would be better to postpone it until the di= scovery > layer, which this draft clearly relies upon, is a bit clearer. I would be= satisfied > with a simple note stating that if the discovery work at the APP area isn= 't > complete, the WG may choose to delay work on this document until ready. > > > > EH > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > >> Sent: Sunday, April 15, 2012 9:01 AM > >> To: Eran Hammer > >> Cc: Hannes Tschofenig; oauth@ietf.org WG > >> Subject: Re: [OAUTH-WG] Dynamic Client Registration > >> > >> Hi Eran, > >> > >> you are saying that you are not interested in the dynamic client > >> registration work and that's OK. There are, however, a couple of > >> other folks in the group who had expressed interest to work on it, to > review and to implement it. > >> > >> Note also that the discovery and the dynamic client registration is > >> different from each other; there is a relationship but they are > nevertheless different. > >> > >> Ciao > >> Hannes > >> > >> PS: Moving the Simple Web Discovery to the Apps area working group > >> does not mean that it will not be done. On the contrary there will be > >> work happing and we are just trying to figure out what the difference > >> between SWD and WebFinger is. > >> > >> On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote: > >> > >>> I'd like to see 'Dynamic Client Registration' removed from the > >>> charter along > >> with SWD for the sole reason that figuring out a generic discovery > >> mechanism is going to take some time and this WG has enough other > >> work to focus on while that happens elsewhere. I expect this to come > >> back in the next round with much more deployment experience and > discovery clarity. > >>> EH > >>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>> Behalf Of Hannes Tschofenig > >>>> Sent: Friday, April 13, 2012 7:36 AM > >>>> To: oauth@ietf.org WG > >>>> Subject: [OAUTH-WG] Dynamic Client Registration > >>>> > >>>> Hi all, > >>>> > >>>> at the IETF#83 OAuth working group meeting we had some confusion > >>>> about the Dynamic Client Registration and the Simple Web Discovery > >>>> item. I just listened to the audio recording again. > >>>> > >>>> With the ongoing mailing list discussion regarding WebFinger vs. > >>>> Simple Web Discovery I hope that folks had a chance to look at the > >>>> documents again and so the confusion of some got resolved. > >>>> > >>>> I believe the proposed new charter item is sufficiently clear with > >>>> regard to the scope of the work. Right? > >>>> Here is the item again: > >>>> " > >>>> Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to > >>>> the IESG for consideration as a Proposed Standard > >>>> > >>>> [Starting point for the work will be > >>>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg > >>>> ] > >>>> " > >>>> > >>>> Of course there there is a relationship between Simple Web > >>>> Discovery (or > >>>> WebFinger) and the dynamic client registration since the client > >>>> first needs to discover the client registration endpoint at the > >>>> authorization server before interacting with it. > >>>> > >>>> Now, one thing that just came to my mind when looking again at > >>>> draft- hardjono-oauth-dynreq was the following: Could the Client > >>>> Registration Request and Response protocol exchange could become a > >>>> profile of the SCIM protocol? In some sense this exchange is > >>>> nothing else than provisioning an account at the Authorization > >>>> Server (along with > >> some meta-data). > >>>> Is this too far fetched? > >>>> > >>>> 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 From torsten@lodderstedt.net Wed Apr 18 12:53:09 2012 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 DE57F11E8089 for ; Wed, 18 Apr 2012 12:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiEhb4eB3Mng for ; Wed, 18 Apr 2012 12:53:06 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by ietfa.amsl.com (Postfix) with ESMTP id D423011E8096 for ; Wed, 18 Apr 2012 12:53:05 -0700 (PDT) Received: from [79.253.18.109] (helo=[192.168.71.36]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SKaw2-0001lH-Cj; Wed, 18 Apr 2012 21:53:02 +0200 Message-ID: <4F8F1B9F.1040302@lodderstedt.net> Date: Wed, 18 Apr 2012 21:53:03 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Justin Richer References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F88713C.6070309@mitre.org> <4F8C6D43.2030701@mitre.org> In-Reply-To: <4F8C6D43.2030701@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: Derek Atkins , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Wed, 18 Apr 2012 19:53:10 -0000 Hi all, is there enough experience in the field with such an interface to standardize it? I would expect such an endpoint to return the same payload, which is carried in a JSON Web Token. So once we designed the JSON Web Tokens content, designing the AS-PR interface could be the next logical step (after the next re-charting). regards, Torsten. Am 16.04.2012 21:04, schrieb Justin Richer: > >>> OK, but with SWD and discovery off the table, can this now be >>> considered to be within that manageable number instead? >> We wanted to keep the # of WG items to approximately 5. Once we finish >> some of these items and get them off our plate we could roll new items >> onto the plate, theoretically. >> > > That's definitely true going forward, but what I was saying is that > the number of items under consideration is now down to 4, with SWD > moving to the Apps group. I was proposing that the whole introspection > endpoint and general AS-PR connection could be this group's fifth > starting document. > > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Wed Apr 18 12:56:55 2012 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 2941C11E8094 for ; Wed, 18 Apr 2012 12:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMBaYdRGNixp for ; Wed, 18 Apr 2012 12:56:51 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) by ietfa.amsl.com (Postfix) with ESMTP id E471911E8096 for ; Wed, 18 Apr 2012 12:56:50 -0700 (PDT) Received: from [79.253.18.109] (helo=[192.168.71.36]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SKazh-0007V9-7N; Wed, 18 Apr 2012 21:56:49 +0200 Message-ID: <4F8F1C83.2000107@lodderstedt.net> Date: Wed, 18 Apr 2012 21:56:51 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Eran Hammer References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F47@P3PWEX2MB008.ex2.secureserver.net> <6760C38E-7C0C-412F-A285-8F4CB2858F30@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE92E4@P3PWEX2MB008.ex2.secureserver.net> <4F8F1ACE.4030407@lodderstedt.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFCD2@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFCD2@P3PWEX2MB008.ex2.secureserver.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration 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: Wed, 18 Apr 2012 19:56:55 -0000 Hi Eran, thanks for pointing this out. I took a quick look on the document. Seems the I-D combines registration and discovery. I think both should be kept separat. So I would suggest to remove section 5 and the dependency is gone. regards, Torsten. Am 18.04.2012 21:51, schrieb Eran Hammer: > Because it is in the draft the WG is suppose to consider. It's a stated dependency. > > EH > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Wednesday, April 18, 2012 12:50 PM >> To: Eran Hammer >> Cc: Hannes Tschofenig; oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Dynamic Client Registration >> >> Hi Eran, >> >> why do you see a relationship between dynamic client registration and >> discovery? Basically, we don't care so far how a client finds tokens and end- >> user authorization point. Why is this any different for the client registration >> endpoint (or the revocation endpoint)? Or do you have a bigger picture in >> mind? >> >> regards, >> Torsten. >> >> Am 15.04.2012 22:36, schrieb Eran Hammer: >>> Where did I say I'm not interested in this work?! >>> >>> All I was saying is that it would be better to postpone it until the discovery >> layer, which this draft clearly relies upon, is a bit clearer. I would be satisfied >> with a simple note stating that if the discovery work at the APP area isn't >> complete, the WG may choose to delay work on this document until ready. >>> EH >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >>>> Sent: Sunday, April 15, 2012 9:01 AM >>>> To: Eran Hammer >>>> Cc: Hannes Tschofenig; oauth@ietf.org WG >>>> Subject: Re: [OAUTH-WG] Dynamic Client Registration >>>> >>>> Hi Eran, >>>> >>>> you are saying that you are not interested in the dynamic client >>>> registration work and that's OK. There are, however, a couple of >>>> other folks in the group who had expressed interest to work on it, to >> review and to implement it. >>>> Note also that the discovery and the dynamic client registration is >>>> different from each other; there is a relationship but they are >> nevertheless different. >>>> Ciao >>>> Hannes >>>> >>>> PS: Moving the Simple Web Discovery to the Apps area working group >>>> does not mean that it will not be done. On the contrary there will be >>>> work happing and we are just trying to figure out what the difference >>>> between SWD and WebFinger is. >>>> >>>> On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote: >>>> >>>>> I'd like to see 'Dynamic Client Registration' removed from the >>>>> charter along >>>> with SWD for the sole reason that figuring out a generic discovery >>>> mechanism is going to take some time and this WG has enough other >>>> work to focus on while that happens elsewhere. I expect this to come >>>> back in the next round with much more deployment experience and >> discovery clarity. >>>>> EH >>>>> >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>> Behalf Of Hannes Tschofenig >>>>>> Sent: Friday, April 13, 2012 7:36 AM >>>>>> To: oauth@ietf.org WG >>>>>> Subject: [OAUTH-WG] Dynamic Client Registration >>>>>> >>>>>> Hi all, >>>>>> >>>>>> at the IETF#83 OAuth working group meeting we had some confusion >>>>>> about the Dynamic Client Registration and the Simple Web Discovery >>>>>> item. I just listened to the audio recording again. >>>>>> >>>>>> With the ongoing mailing list discussion regarding WebFinger vs. >>>>>> Simple Web Discovery I hope that folks had a chance to look at the >>>>>> documents again and so the confusion of some got resolved. >>>>>> >>>>>> I believe the proposed new charter item is sufficiently clear with >>>>>> regard to the scope of the work. Right? >>>>>> Here is the item again: >>>>>> " >>>>>> Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to >>>>>> the IESG for consideration as a Proposed Standard >>>>>> >>>>>> [Starting point for the work will be >>>>>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg >>>>>> ] >>>>>> " >>>>>> >>>>>> Of course there there is a relationship between Simple Web >>>>>> Discovery (or >>>>>> WebFinger) and the dynamic client registration since the client >>>>>> first needs to discover the client registration endpoint at the >>>>>> authorization server before interacting with it. >>>>>> >>>>>> Now, one thing that just came to my mind when looking again at >>>>>> draft- hardjono-oauth-dynreq was the following: Could the Client >>>>>> Registration Request and Response protocol exchange could become a >>>>>> profile of the SCIM protocol? In some sense this exchange is >>>>>> nothing else than provisioning an account at the Authorization >>>>>> Server (along with >>>> some meta-data). >>>>>> Is this too far fetched? >>>>>> >>>>>> 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 From jricher@mitre.org Wed Apr 18 13:00:55 2012 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 0C68811E809A for ; Wed, 18 Apr 2012 13:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeACE-wXetPJ for ; Wed, 18 Apr 2012 13:00:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 301FE11E8097 for ; Wed, 18 Apr 2012 13:00:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7A13321B1BD5; Wed, 18 Apr 2012 16:00:43 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6990F21B1BCF; Wed, 18 Apr 2012 16:00:43 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 18 Apr 2012 16:00:43 -0400 Message-ID: <4F8F1D44.7090006@mitre.org> Date: Wed, 18 Apr 2012 16:00:04 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Eran Hammer References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F47@P3PWEX2MB008.ex2.secureserver.net> <6760C38E-7C0C-412F-A285-8F4CB2858F30@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE92E4@P3PWEX2MB008.ex2.secureserver.net> <4F8F1ACE.4030407@lodderstedt.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFCD2@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFCD2@P3PWEX2MB008.ex2.secureserver.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration 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: Wed, 18 Apr 2012 20:00:55 -0000 So it's a "known issue". I think that's an artificial reason to leave it and a reasonable section to be cut out first. -- Justin On 04/18/2012 03:51 PM, Eran Hammer wrote: > Because it is in the draft the WG is suppose to consider. It's a stated dependency. > > EH > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Wednesday, April 18, 2012 12:50 PM >> To: Eran Hammer >> Cc: Hannes Tschofenig; oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Dynamic Client Registration >> >> Hi Eran, >> >> why do you see a relationship between dynamic client registration and >> discovery? Basically, we don't care so far how a client finds tokens and end- >> user authorization point. Why is this any different for the client registration >> endpoint (or the revocation endpoint)? Or do you have a bigger picture in >> mind? >> >> regards, >> Torsten. >> >> Am 15.04.2012 22:36, schrieb Eran Hammer: >>> Where did I say I'm not interested in this work?! >>> >>> All I was saying is that it would be better to postpone it until the discovery >> layer, which this draft clearly relies upon, is a bit clearer. I would be satisfied >> with a simple note stating that if the discovery work at the APP area isn't >> complete, the WG may choose to delay work on this document until ready. >>> EH >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >>>> Sent: Sunday, April 15, 2012 9:01 AM >>>> To: Eran Hammer >>>> Cc: Hannes Tschofenig; oauth@ietf.org WG >>>> Subject: Re: [OAUTH-WG] Dynamic Client Registration >>>> >>>> Hi Eran, >>>> >>>> you are saying that you are not interested in the dynamic client >>>> registration work and that's OK. There are, however, a couple of >>>> other folks in the group who had expressed interest to work on it, to >> review and to implement it. >>>> Note also that the discovery and the dynamic client registration is >>>> different from each other; there is a relationship but they are >> nevertheless different. >>>> Ciao >>>> Hannes >>>> >>>> PS: Moving the Simple Web Discovery to the Apps area working group >>>> does not mean that it will not be done. On the contrary there will be >>>> work happing and we are just trying to figure out what the difference >>>> between SWD and WebFinger is. >>>> >>>> On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote: >>>> >>>>> I'd like to see 'Dynamic Client Registration' removed from the >>>>> charter along >>>> with SWD for the sole reason that figuring out a generic discovery >>>> mechanism is going to take some time and this WG has enough other >>>> work to focus on while that happens elsewhere. I expect this to come >>>> back in the next round with much more deployment experience and >> discovery clarity. >>>>> EH >>>>> >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>> Behalf Of Hannes Tschofenig >>>>>> Sent: Friday, April 13, 2012 7:36 AM >>>>>> To: oauth@ietf.org WG >>>>>> Subject: [OAUTH-WG] Dynamic Client Registration >>>>>> >>>>>> Hi all, >>>>>> >>>>>> at the IETF#83 OAuth working group meeting we had some confusion >>>>>> about the Dynamic Client Registration and the Simple Web Discovery >>>>>> item. I just listened to the audio recording again. >>>>>> >>>>>> With the ongoing mailing list discussion regarding WebFinger vs. >>>>>> Simple Web Discovery I hope that folks had a chance to look at the >>>>>> documents again and so the confusion of some got resolved. >>>>>> >>>>>> I believe the proposed new charter item is sufficiently clear with >>>>>> regard to the scope of the work. Right? >>>>>> Here is the item again: >>>>>> " >>>>>> Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to >>>>>> the IESG for consideration as a Proposed Standard >>>>>> >>>>>> [Starting point for the work will be >>>>>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg >>>>>> ] >>>>>> " >>>>>> >>>>>> Of course there there is a relationship between Simple Web >>>>>> Discovery (or >>>>>> WebFinger) and the dynamic client registration since the client >>>>>> first needs to discover the client registration endpoint at the >>>>>> authorization server before interacting with it. >>>>>> >>>>>> Now, one thing that just came to my mind when looking again at >>>>>> draft- hardjono-oauth-dynreq was the following: Could the Client >>>>>> Registration Request and Response protocol exchange could become a >>>>>> profile of the SCIM protocol? In some sense this exchange is >>>>>> nothing else than provisioning an account at the Authorization >>>>>> Server (along with >>>> some meta-data). >>>>>> Is this too far fetched? >>>>>> >>>>>> 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 From jricher@mitre.org Wed Apr 18 13:02:08 2012 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 ED0FE21F8438 for ; Wed, 18 Apr 2012 13:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeOld8TUXYh6 for ; Wed, 18 Apr 2012 13:02:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EBD7721E800F for ; Wed, 18 Apr 2012 13:02:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1E79821B02C4; Wed, 18 Apr 2012 16:02:03 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 17C8021B02A5; Wed, 18 Apr 2012 16:02:03 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 18 Apr 2012 16:02:02 -0400 Message-ID: <4F8F1D94.4090208@mitre.org> Date: Wed, 18 Apr 2012 16:01:24 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Torsten Lodderstedt References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F88713C.6070309@mitre.org> <4F8C6D43.2030701@mitre.org> <4F8F1B9F.1040302@lodderstedt.net> In-Reply-To: <4F8F1B9F.1040302@lodderstedt.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: Derek Atkins , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Wed, 18 Apr 2012 20:02:09 -0000 Not all implementations in the field that do this are using JWTs as the tokens. Ours in particular used a random blob with no structured information in it. The endpoint returned a JSON object. -- Justin On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: > Hi all, > > is there enough experience in the field with such an interface to > standardize it? > > I would expect such an endpoint to return the same payload, which is > carried in a JSON Web Token. So once we designed the JSON Web Tokens > content, designing the AS-PR interface could be the next logical step > (after the next re-charting). > > regards, > Torsten. > > Am 16.04.2012 21:04, schrieb Justin Richer: >> >>>> OK, but with SWD and discovery off the table, can this now be >>>> considered to be within that manageable number instead? >>> We wanted to keep the # of WG items to approximately 5. Once we finish >>> some of these items and get them off our plate we could roll new items >>> onto the plate, theoretically. >>> >> >> That's definitely true going forward, but what I was saying is that >> the number of items under consideration is now down to 4, with SWD >> moving to the Apps group. I was proposing that the whole >> introspection endpoint and general AS-PR connection could be this >> group's fifth starting document. >> >> -- Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Apr 18 13:02:21 2012 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 9D87421F842B for ; Wed, 18 Apr 2012 13:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1ow+069lg1K for ; Wed, 18 Apr 2012 13:02:17 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCDC11E80B0 for ; Wed, 18 Apr 2012 13:02:17 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id zY2H1i0020EuLVk01Y2HNA; Wed, 18 Apr 2012 13:02:17 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Wed, 18 Apr 2012 13:02:16 -0700 From: Eran Hammer To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Dynamic Client Registration Thread-Index: AQHNGYLIAhnVBxyYNEuwmb5Seq6ic5abalPQgAEZ9wD//9bm0IAFH+QA//+LAjCAAHcHgP//i/bA Date: Wed, 18 Apr 2012 20:02:16 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFD69@P3PWEX2MB008.ex2.secureserver.net> References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F47@P3PWEX2MB008.ex2.secureserver.net> <6760C38E-7C0C-412F-A285-8F4CB2858F30@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE92E4@P3PWEX2MB008.ex2.secureserver.net> <4F8F1ACE.4030407@lodderstedt.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFCD2@P3PWEX2MB008.ex2.secureserver.net> <4F8F1C83.2000107@lodderstedt.net> In-Reply-To: <4F8F1C83.2000107@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [63.79.89.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic Client Registration 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: Wed, 18 Apr 2012 20:02:21 -0000 WFM. An updated I-D without it would be great. EH > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Wednesday, April 18, 2012 12:57 PM > To: Eran Hammer > Cc: Hannes Tschofenig; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Dynamic Client Registration >=20 > Hi Eran, >=20 > thanks for pointing this out. I took a quick look on the document. Seems = the > I-D combines registration and discovery. I think both should be kept sepa= rat. > So I would suggest to remove section 5 and the dependency is gone. >=20 > regards, > Torsten. >=20 > Am 18.04.2012 21:51, schrieb Eran Hammer: > > Because it is in the draft the WG is suppose to consider. It's a stated > dependency. > > > > EH > > > >> -----Original Message----- > >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > >> Sent: Wednesday, April 18, 2012 12:50 PM > >> To: Eran Hammer > >> Cc: Hannes Tschofenig; oauth@ietf.org WG > >> Subject: Re: [OAUTH-WG] Dynamic Client Registration > >> > >> Hi Eran, > >> > >> why do you see a relationship between dynamic client registration and > >> discovery? Basically, we don't care so far how a client finds tokens > >> and end- user authorization point. Why is this any different for the > >> client registration endpoint (or the revocation endpoint)? Or do you > >> have a bigger picture in mind? > >> > >> regards, > >> Torsten. > >> > >> Am 15.04.2012 22:36, schrieb Eran Hammer: > >>> Where did I say I'm not interested in this work?! > >>> > >>> All I was saying is that it would be better to postpone it until the > >>> discovery > >> layer, which this draft clearly relies upon, is a bit clearer. I > >> would be satisfied with a simple note stating that if the discovery > >> work at the APP area isn't complete, the WG may choose to delay work > on this document until ready. > >>> EH > >>> > >>>> -----Original Message----- > >>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > >>>> Sent: Sunday, April 15, 2012 9:01 AM > >>>> To: Eran Hammer > >>>> Cc: Hannes Tschofenig; oauth@ietf.org WG > >>>> Subject: Re: [OAUTH-WG] Dynamic Client Registration > >>>> > >>>> Hi Eran, > >>>> > >>>> you are saying that you are not interested in the dynamic client > >>>> registration work and that's OK. There are, however, a couple of > >>>> other folks in the group who had expressed interest to work on it, > >>>> to > >> review and to implement it. > >>>> Note also that the discovery and the dynamic client registration is > >>>> different from each other; there is a relationship but they are > >> nevertheless different. > >>>> Ciao > >>>> Hannes > >>>> > >>>> PS: Moving the Simple Web Discovery to the Apps area working group > >>>> does not mean that it will not be done. On the contrary there will > >>>> be work happing and we are just trying to figure out what the > >>>> difference between SWD and WebFinger is. > >>>> > >>>> On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote: > >>>> > >>>>> I'd like to see 'Dynamic Client Registration' removed from the > >>>>> charter along > >>>> with SWD for the sole reason that figuring out a generic discovery > >>>> mechanism is going to take some time and this WG has enough other > >>>> work to focus on while that happens elsewhere. I expect this to > >>>> come back in the next round with much more deployment experience > >>>> and > >> discovery clarity. > >>>>> EH > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>>>> Behalf Of Hannes Tschofenig > >>>>>> Sent: Friday, April 13, 2012 7:36 AM > >>>>>> To: oauth@ietf.org WG > >>>>>> Subject: [OAUTH-WG] Dynamic Client Registration > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> at the IETF#83 OAuth working group meeting we had some > confusion > >>>>>> about the Dynamic Client Registration and the Simple Web > >>>>>> Discovery item. I just listened to the audio recording again. > >>>>>> > >>>>>> With the ongoing mailing list discussion regarding WebFinger vs. > >>>>>> Simple Web Discovery I hope that folks had a chance to look at > >>>>>> the documents again and so the confusion of some got resolved. > >>>>>> > >>>>>> I believe the proposed new charter item is sufficiently clear > >>>>>> with regard to the scope of the work. Right? > >>>>>> Here is the item again: > >>>>>> " > >>>>>> Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to > >>>>>> the IESG for consideration as a Proposed Standard > >>>>>> > >>>>>> [Starting point for the work will be > >>>>>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg > >>>>>> ] > >>>>>> " > >>>>>> > >>>>>> Of course there there is a relationship between Simple Web > >>>>>> Discovery (or > >>>>>> WebFinger) and the dynamic client registration since the client > >>>>>> first needs to discover the client registration endpoint at the > >>>>>> authorization server before interacting with it. > >>>>>> > >>>>>> Now, one thing that just came to my mind when looking again at > >>>>>> draft- hardjono-oauth-dynreq was the following: Could the Client > >>>>>> Registration Request and Response protocol exchange could > become > >>>>>> a profile of the SCIM protocol? In some sense this exchange is > >>>>>> nothing else than provisioning an account at the Authorization > >>>>>> Server (along with > >>>> some meta-data). > >>>>>> Is this too far fetched? > >>>>>> > >>>>>> 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 From torsten@lodderstedt.net Wed Apr 18 13:10:09 2012 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 50F5921F847D for ; Wed, 18 Apr 2012 13:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYnvXxI31isN for ; Wed, 18 Apr 2012 13:10:05 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by ietfa.amsl.com (Postfix) with ESMTP id E0B2321F847C for ; Wed, 18 Apr 2012 13:10:04 -0700 (PDT) Received: from [79.253.18.109] (helo=[192.168.71.36]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SKbCU-0002Ln-HR; Wed, 18 Apr 2012 22:10:02 +0200 Message-ID: <4F8F1F9C.7020008@lodderstedt.net> Date: Wed, 18 Apr 2012 22:10:04 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Justin Richer References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F88713C.6070309@mitre.org> <4F8C6D43.2030701@mitre.org> <4F8F1B9F.1040302@lodderstedt.net> <4F8F1D94.4090208@mitre.org> In-Reply-To: <4F8F1D94.4090208@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: Derek Atkins , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Wed, 18 Apr 2012 20:10:09 -0000 Hi Justin, I refered to the data format used at the AS-PR interface. According to your description, you use JSON objects there. What data does such an object contain? Is this any different from a JSON Web Token (leaving aside digital signatures and encryption)? regards, Torsten. Am 18.04.2012 22:01, schrieb Justin Richer: > Not all implementations in the field that do this are using JWTs as > the tokens. Ours in particular used a random blob with no structured > information in it. The endpoint returned a JSON object. > > -- Justin > > On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: >> Hi all, >> >> is there enough experience in the field with such an interface to >> standardize it? >> >> I would expect such an endpoint to return the same payload, which is >> carried in a JSON Web Token. So once we designed the JSON Web Tokens >> content, designing the AS-PR interface could be the next logical step >> (after the next re-charting). >> >> regards, >> Torsten. >> >> Am 16.04.2012 21:04, schrieb Justin Richer: >>> >>>>> OK, but with SWD and discovery off the table, can this now be >>>>> considered to be within that manageable number instead? >>>> We wanted to keep the # of WG items to approximately 5. Once we >>>> finish >>>> some of these items and get them off our plate we could roll new items >>>> onto the plate, theoretically. >>>> >>> >>> That's definitely true going forward, but what I was saying is that >>> the number of items under consideration is now down to 4, with SWD >>> moving to the Apps group. I was proposing that the whole >>> introspection endpoint and general AS-PR connection could be this >>> group's fifth starting document. >>> >>> -- Justin >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > From igor.faynberg@alcatel-lucent.com Wed Apr 18 13:17:08 2012 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 83A7521F8433 for ; Wed, 18 Apr 2012 13:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.339 X-Spam-Level: X-Spam-Status: No, score=-9.339 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBfDWtMSJdW7 for ; Wed, 18 Apr 2012 13:17:05 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8C10F11E8085 for ; Wed, 18 Apr 2012 13:17:04 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q3IKH3Ln016301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Apr 2012 15:17:03 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3IKH3IJ004281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 18 Apr 2012 15:17:03 -0500 Received: from [135.222.232.147] (USMUYN0L055118.mh.lucent.com [135.222.232.147]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3IKH2R2020475; Wed, 18 Apr 2012 15:17:03 -0500 (CDT) Message-ID: <4F8F213E.40003@alcatel-lucent.com> Date: Wed, 18 Apr 2012 16:17:02 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <5F51A14F-D548-4D29-B20F-5C3DCB3CB705@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE7F47@P3PWEX2MB008.ex2.secureserver.net> <6760C38E-7C0C-412F-A285-8F4CB2858F30@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FE92E4@P3PWEX2MB008.ex2.secureserver.net> <4F8F1ACE.4030407@lodderstedt.net> <0CBAEB56DDB3A140BA8E8C124C04ECA2FEFCD2@P3PWEX2MB008.ex2.secureserver.net> <4F8F1C83.2000107@lodderstedt.net> In-Reply-To: <4F8F1C83.2000107@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] Dynamic Client Registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:17:08 -0000 +1 for keeping registration and discovery separate. (As is typical, Torsten had beaten me to saying just what I was thinking about and preparing to to say. The only consolation is that he expressed it better than I would have.) Igor On 4/18/2012 3:56 PM, Torsten Lodderstedt wrote: > Hi Eran, > > thanks for pointing this out. I took a quick look on the document. > Seems the I-D combines registration and discovery. I think both should > be kept separat. So I would suggest to remove section 5 and the > dependency is gone. > > regards, > Torsten. > > Am 18.04.2012 21:51, schrieb Eran Hammer: >> Because it is in the draft the WG is suppose to consider. It's a >> stated dependency. >> >> EH >> >>> -----Original Message----- >>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >>> Sent: Wednesday, April 18, 2012 12:50 PM >>> To: Eran Hammer >>> Cc: Hannes Tschofenig; oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] Dynamic Client Registration >>> >>> Hi Eran, >>> >>> why do you see a relationship between dynamic client registration and >>> discovery? Basically, we don't care so far how a client finds tokens >>> and end- >>> user authorization point. Why is this any different for the client >>> registration >>> endpoint (or the revocation endpoint)? Or do you have a bigger >>> picture in >>> mind? >>> >>> regards, >>> Torsten. >>> >>> Am 15.04.2012 22:36, schrieb Eran Hammer: >>>> Where did I say I'm not interested in this work?! >>>> >>>> All I was saying is that it would be better to postpone it until >>>> the discovery >>> layer, which this draft clearly relies upon, is a bit clearer. I >>> would be satisfied >>> with a simple note stating that if the discovery work at the APP >>> area isn't >>> complete, the WG may choose to delay work on this document until ready. >>>> EH >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >>>>> Sent: Sunday, April 15, 2012 9:01 AM >>>>> To: Eran Hammer >>>>> Cc: Hannes Tschofenig; oauth@ietf.org WG >>>>> Subject: Re: [OAUTH-WG] Dynamic Client Registration >>>>> >>>>> Hi Eran, >>>>> >>>>> you are saying that you are not interested in the dynamic client >>>>> registration work and that's OK. There are, however, a couple of >>>>> other folks in the group who had expressed interest to work on it, to >>> review and to implement it. >>>>> Note also that the discovery and the dynamic client registration is >>>>> different from each other; there is a relationship but they are >>> nevertheless different. >>>>> Ciao >>>>> Hannes >>>>> >>>>> PS: Moving the Simple Web Discovery to the Apps area working group >>>>> does not mean that it will not be done. On the contrary there will be >>>>> work happing and we are just trying to figure out what the difference >>>>> between SWD and WebFinger is. >>>>> >>>>> On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote: >>>>> >>>>>> I'd like to see 'Dynamic Client Registration' removed from the >>>>>> charter along >>>>> with SWD for the sole reason that figuring out a generic discovery >>>>> mechanism is going to take some time and this WG has enough other >>>>> work to focus on while that happens elsewhere. I expect this to come >>>>> back in the next round with much more deployment experience and >>> discovery clarity. >>>>>> EH >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>>> Behalf Of Hannes Tschofenig >>>>>>> Sent: Friday, April 13, 2012 7:36 AM >>>>>>> To: oauth@ietf.org WG >>>>>>> Subject: [OAUTH-WG] Dynamic Client Registration >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> at the IETF#83 OAuth working group meeting we had some confusion >>>>>>> about the Dynamic Client Registration and the Simple Web Discovery >>>>>>> item. I just listened to the audio recording again. >>>>>>> >>>>>>> With the ongoing mailing list discussion regarding WebFinger vs. >>>>>>> Simple Web Discovery I hope that folks had a chance to look at the >>>>>>> documents again and so the confusion of some got resolved. >>>>>>> >>>>>>> I believe the proposed new charter item is sufficiently clear with >>>>>>> regard to the scope of the work. Right? >>>>>>> Here is the item again: >>>>>>> " >>>>>>> Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to >>>>>>> the IESG for consideration as a Proposed Standard >>>>>>> >>>>>>> [Starting point for the work will be >>>>>>> http://tools.ietf.org/html/draft-hardjono-oauth-dynreg >>>>>>> ] >>>>>>> " >>>>>>> >>>>>>> Of course there there is a relationship between Simple Web >>>>>>> Discovery (or >>>>>>> WebFinger) and the dynamic client registration since the client >>>>>>> first needs to discover the client registration endpoint at the >>>>>>> authorization server before interacting with it. >>>>>>> >>>>>>> Now, one thing that just came to my mind when looking again at >>>>>>> draft- hardjono-oauth-dynreq was the following: Could the Client >>>>>>> Registration Request and Response protocol exchange could become a >>>>>>> profile of the SCIM protocol? In some sense this exchange is >>>>>>> nothing else than provisioning an account at the Authorization >>>>>>> Server (along with >>>>> some meta-data). >>>>>>> Is this too far fetched? >>>>>>> >>>>>>> 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 From jricher@mitre.org Wed Apr 18 13:24:23 2012 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 4759511E8085 for ; Wed, 18 Apr 2012 13:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzbTSTnYGbbX for ; Wed, 18 Apr 2012 13:24:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F203111E8080 for ; Wed, 18 Apr 2012 13:24:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A12A821B02BD; Wed, 18 Apr 2012 16:24:11 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9A26421B02A7; Wed, 18 Apr 2012 16:24:11 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 18 Apr 2012 16:24:11 -0400 Message-ID: <4F8F22C4.6000900@mitre.org> Date: Wed, 18 Apr 2012 16:23:32 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Torsten Lodderstedt References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F88713C.6070309@mitre.org> <4F8C6D43.2030701@mitre.org> <4F8F1B9F.1040302@lodderstedt.net> <4F8F1D94.4090208@mitre.org> <4F8F1F9C.7020008@lodderstedt.net> In-Reply-To: <4F8F1F9C.7020008@lodderstedt.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: Derek Atkins , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Wed, 18 Apr 2012 20:24:23 -0000 I think we might be crossing wires about input to the token introspection endpoint vs. output from it. In OpenID Connect, you send a JWT in, and get back a JSON object that represents the Claims bit of the JWT. In our implementation (and I think both Ping and AOL's), you send in an arbitrary token (with no proscribed format) and get back a JSON object with different pieces in it. Ours included a list of scopes and an expiration timestamp, others did different things, like audience and issuer, as part of the return. The point I was trying to make is that the information returned from the AS-PR interface isn't necessarily embedded inside of the token used to call that interface. In OpenID Connect, it is, and the CheckID endpoint just unwraps the JWT for you. In the larger case, what's really going on is that the PR presents a token that it's not sure what it's good for and gets back something that answers that question. Since a JWT Claims section can be an arbitrary JSON object (for all intents and purposes), you could use a JWT as the output of the introspection endpoint as well. -- Justin On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote: > Hi Justin, > > I refered to the data format used at the AS-PR interface. According to > your description, you use JSON objects there. What data does such an > object contain? Is this any different from a JSON Web Token (leaving > aside digital signatures and encryption)? > > regards, > Torsten. > > Am 18.04.2012 22:01, schrieb Justin Richer: >> Not all implementations in the field that do this are using JWTs as >> the tokens. Ours in particular used a random blob with no structured >> information in it. The endpoint returned a JSON object. >> >> -- Justin >> >> On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: >>> Hi all, >>> >>> is there enough experience in the field with such an interface to >>> standardize it? >>> >>> I would expect such an endpoint to return the same payload, which is >>> carried in a JSON Web Token. So once we designed the JSON Web Tokens >>> content, designing the AS-PR interface could be the next logical >>> step (after the next re-charting). >>> >>> regards, >>> Torsten. >>> >>> Am 16.04.2012 21:04, schrieb Justin Richer: >>>> >>>>>> OK, but with SWD and discovery off the table, can this now be >>>>>> considered to be within that manageable number instead? >>>>> We wanted to keep the # of WG items to approximately 5. Once we >>>>> finish >>>>> some of these items and get them off our plate we could roll new >>>>> items >>>>> onto the plate, theoretically. >>>>> >>>> >>>> That's definitely true going forward, but what I was saying is that >>>> the number of items under consideration is now down to 4, with SWD >>>> moving to the Apps group. I was proposing that the whole >>>> introspection endpoint and general AS-PR connection could be this >>>> group's fifth starting document. >>>> >>>> -- Justin >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> From andreas.solberg@uninett.no Thu Apr 19 01:29:58 2012 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 AE6D621F8557 for ; Thu, 19 Apr 2012 01:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnvmh0EisWx3 for ; Thu, 19 Apr 2012 01:29:53 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:0:526:158:38:180:100]) by ietfa.amsl.com (Postfix) with ESMTP id 7436421F8589 for ; Thu, 19 Apr 2012 01:29:52 -0700 (PDT) Received: from dmanso-11.uninett.no (dmanso-11.uninett.no [IPv6:2001:700:1:0:ea06:88ff:fecf:91f7]) by epost.uninett.no (Postfix) with ESMTPS id A2FD8336143 for ; Thu, 19 Apr 2012 10:29:51 +0200 (CEST) From: =?iso-8859-1?Q?Andreas_=C5kre_Solberg?= Content-Type: multipart/signed; boundary="Apple-Mail=_73DC1D3A-6324-413B-91E6-9640538CE0E6"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 19 Apr 2012 10:29:51 +0200 Message-Id: <8F2CE30B-E2CA-4AFF-AAAC-6D1D98BA4400@uninett.no> To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [OAUTH-WG] Best-Practice for dealing with OAuth 2.0 Token expiration at the Consumer 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: Thu, 19 Apr 2012 08:29:58 -0000 --Apple-Mail=_73DC1D3A-6324-413B-91E6-9640538CE0E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Please give me feedback if I got anything wrong, or if you have = comments. = https://rnd.feide.no/2012/04/19/best-practice-for-dealing-with-oauth-2-0-t= oken-expiration-at-the-consumer/ Kind regards, Andreas =C5kre Solberg UNINETT =20= --Apple-Mail=_73DC1D3A-6324-413B-91E6-9640538CE0E6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOazCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIE2jCCA8KgAwIBAgIQXf9Q6v4PU0aIn4BBj+dCyDANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0wOTA1MTgwMDAwMDBaFw0yODEyMzEyMzU5NTlaMEQxCzAJBgNV BAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJzb25h bCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMS8JX3N71kEq3QnKbZjiu/ENXCh RgivblCbG3F4lwKFwDX/kBgRZvozORSepBL3Pe4FLIHn9y0uNnhDDjm2f3p0w8tVPy+zy8M3auGV AyMbsyKYE4NYMF+sPJFF020LLsvRkWGyynH6wokMewnWkr+jgRcRVSDfN4GfHiYJHdIXGUPLi5kl dEFb5jIq0KdT3NIhjc2Rz3ts9Mn+0OXSBmsaYUIbgJEH3BRJJzsKirLiO2kIhMuBmde6FB/YfpJj vfYtMfqVTs02DZnvEbqtSvuoxHi5fFo+yPUIMsCpBceMGiiPMLoXo/G54genuPtVv59iWtUUDwi0 E5nSEnla8P0CAwEAAaOCAVswggFXMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0G A1UdDgQWBBTIiXOZp11RFlNFVHyjwjl8y9eqgTAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgw BgEB/wIBADAmBgNVHSAEHzAdMA0GCysGAQQBsjEBAgIdMAwGCiqGSIb3TAUCAgUwWAYDVR0fBFEw TzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbwYIKwYBBQUHAQEEYzBhMDgGCCsGAQUFBzAChixodHRw Oi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQUFBQ2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0 cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEACBekHPkVa7AZYW+gSON6 JO9BVZqgUHDYI9VThkpnjujaVhYYLBsYIYm6mCTuVjTjF4YmvSFa1BmTSuphdE22xISNR+7KLmVt NpOYseKSZojiTnt1x15EaSHcEmow/GGA/g/wndLcfq7lwlNNC3CDYVZF+z3fcvYCQnXriIqYV2D1 n6JySbF6PkFnNcNVKw0HNejGK9W6h3mAdOeSNr1GgXouKeJqvuEXEzV8FqQlMy9h7s7JUuBA29O+ OVrPz0wU5X/FQ1eLTblajsIPBk3eyEmdgXO65D+YpZM8WU7bmzXf/k2/VaHpZMNFfKyPfEfROvFO ddmQZ0DosS+eFy9cNTCCBPswggPjoAMCAQICEQCbXV9Tn+I7grzQTh0VEN6kMA0GCSqGSIb3DQEB BQUAMEQxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2Np ZW5jZSBQZXJzb25hbCBDQTAeFw0xMTA3MDUwMDAwMDBaFw0xMjA4MDMyMzU5NTlaMIGUMRMwEQYK CZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGdGVyZW5hMRMwEQYKCZImiZPyLGQBGRYD dGNzMQswCQYDVQQGEwJOTzEQMA4GA1UEChMHVU5JTkVUVDExMC8GA1UEAxQoQW5kcmVhcyBhYWty ZSBTb2xiZXJnIGFuZHJlYXNAdW5pbmV0dC5ubzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAL8ukoshERFAc4JLOA7WhazD4rpQPdboyAtCuynZUBW2s6NYPH6IuU25CcRldKJIzkBa9/A5 +rmD5r2Evsbdnt91VSU8FR9J73BMHPT7HywD4Y3Rv/h/kb6xkLCgoRAoCPlZDepR6TvUWH1PulII IlbtBMarsrfEUFGuntLIJQA5yH7WysiV0wHGygb+P1KiSDJd4/v3OBilAAg7zwRNJJ5ihmcW24Jx ZX3hQU9KV5ZXb2IxohUwTscYEGBPMoOPe62uQlj2MNiTYaXHX3QH4QZzD4v6MU5qxMSFXxdOfb09 lft3GF+c3PpybQ1T3GpKsSbEcA5FVSMb7HnC67V+5p8CAwEAAaOCAZUwggGRMB8GA1UdIwQYMBaA FMiJc5mnXVEWU0VUfKPCOXzL16qBMB0GA1UdDgQWBBQkb3UBIHXOvsZSkUyjDMTSzXPavDAOBgNV HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw JgYDVR0gBB8wHTANBgsrBgEEAbIxAQICHTAMBgoqhkiG90wFAgIFMEcGA1UdHwRAMD4wPKA6oDiG Nmh0dHA6Ly9jcmwudGNzLnRlcmVuYS5vcmcvVEVSRU5BZVNjaWVuY2VQZXJzb25hbENBLmNybDB6 BggrBgEFBQcBAQRuMGwwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jcnQudGNzLnRlcmVuYS5vcmcvVEVS RU5BZVNjaWVuY2VQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwJQYDVR0RBB4wHIEaYW5kcmVhcy5zb2xiZXJnQHVuaW5ldHQubm8wDQYJKoZIhvcN AQEFBQADggEBAKLxPqSWPfTshbrMWi2qGgUW9eXsVU5Lq31WSJfqN79TVyi4ipHSPE4uKFZOe7ZK AehMM+XNgk59nxpkcPmvksNsY98dk78NyH4dgybY5NLurWptkFbP9npcvBeneb3MEQXDLXfc0MuX daES6X3bxwhqe1nXKsyTFtIe8FBETf6Y+DSfaYY69rL0Vl6yJiDnz5ZYLoXOAr5xZtTbqx/yP9nC yXc5kSR7R2RJIzQ427/sXX4+BK6/rafXaFpMiPjBdOeHMAnT4HBdCtaEk1gjlsxrf5boVlq3MSww DaDMGyCZhhKUmMJ6Uvh/jUeHkxGiw6KxSmRemNSi5FEKBIJ+cQsxggK3MIICswIBATBZMEQxCzAJ BgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExJDAiBgNVBAMTG1RFUkVOQSBlU2NpZW5jZSBQZXJz b25hbCBDQQIRAJtdX1Of4juCvNBOHRUQ3qQwCQYFKw4DAhoFAKCCATMwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNDE5MDgyOTUxWjAjBgkqhkiG9w0BCQQxFgQU zKaY80hlH1wYT+wgvfMb7pqJAVMwaAYJKwYBBAGCNxAEMVswWTBEMQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMSQwIgYDVQQDExtURVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0ECEQCbXV9T n+I7grzQTh0VEN6kMGoGCyqGSIb3DQEJEAILMVugWTBEMQswCQYDVQQGEwJOTDEPMA0GA1UEChMG VEVSRU5BMSQwIgYDVQQDExtURVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0ECEQCbXV9Tn+I7grzQ Th0VEN6kMA0GCSqGSIb3DQEBAQUABIIBAIo5tPUjbbY7JMEMI/X87vszOImK5bKnRcKlWKr5zJw7 wl0c3mJ1ROX7flz4a43npvyPEJpnsBSoWEivC7ecpAzKye9L8srbXPyhCmgRKpzDFpWqAlraE45U e520sKid2pzDz+VYw5YfE8G9KvCw1SmcYD+MULLyKhQK4k3LjD8eW32CE6HTmjDe28MeC6/zso27 2u3Td7RBLCbdlxhcBEM/pYy8ncOA4pvZ0zkCd6IF8mN7wfFuvy7gO/WCwB7F1ACpPOmJmEm/0ujf Uv2+SY4hMKZl0qkLw8mYkwSGCCiFJnT48o+dTQkQzNh3r2Pp/4auPU0ZWmlWXjYQTnAFohEAAAAA AAA= --Apple-Mail=_73DC1D3A-6324-413B-91E6-9640538CE0E6-- From ve7jtb@ve7jtb.com Thu Apr 19 02:51:54 2012 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 A912221F858F for ; Thu, 19 Apr 2012 02:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9GWp1ZJTzOI for ; Thu, 19 Apr 2012 02:51:47 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC78021F8568 for ; Thu, 19 Apr 2012 02:51:42 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so5685090wgb.13 for ; Thu, 19 Apr 2012 02:51:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=wnCvuUe2lZHGKN74eu61GEW1JyxiXi9OfXUZHjurFy8=; b=EL4K6dmSNofSndqA+UVgsDC+BXCHq8aq3jmdlfIUm1RCVl/G97Fq36x+6sFPkBFJhy kL9bgd0ge/j+ntcy/0mrl2QZZbrh7qd47OaulBO7y4uztPyWyPT5GAgRf408pbwTZgHf 7wPFdsge3pcjIuClgLOwkulswQQFQyIs/RE86sWL0wbL46bgvdn6Czv/0HQjideT5VdQ XWvfZ2OuFQmqqWkaKzrSYoJbrF/+Hio3IO6qKxV6ItKrBVliLzqutSNgS/XFcMU0TbMs GqcIppRG+k+X4pLXRDi9CNTVEhiWDRG/D67tRZX9Qm6hWW2BDInV5lGdKc3Ah4k/6qy9 oy9w== Received: by 10.180.78.40 with SMTP id y8mr24721981wiw.15.1334829101238; Thu, 19 Apr 2012 02:51:41 -0700 (PDT) Received: from [10.6.1.77] (nat-VI.gw1.ush2.tnib.de. [86.110.65.2]) by mx.google.com with ESMTPS id w10sm6628533wiy.3.2012.04.19.02.51.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 02:51:36 -0700 (PDT) References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F88713C.6070309@mitre.org> <4F8C6D43.2030701@mitre.org> <4F8F1B9F.1040302@lodderstedt.net> <4F8F1D94.4090208@mitre.org> <4F8F1F9C.7020008@lodderstedt.net> <4F8F22C4.6000900@mitre.org> In-Reply-To: <4F8F22C4.6000900@mitre.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6F00A1D5-1F63-482B-81FF-CA0EC9E77961; protocol="application/pkcs7-signature" Message-Id: <5992B241-D477-4CE2-835A-F163A66AF9D9@ve7jtb.com> X-Mailer: iPad Mail (9B176) From: John Bradley Date: Thu, 19 Apr 2012 11:51:58 +0200 To: Justin Richer X-Gm-Message-State: ALoCoQn0+brjGL2+TcINYWm1l85t9fRxuQj31PxcBDIPn1l5SIGI7hzCj65LlJZjuL2PiAdX0xIV Cc: Derek Atkins , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Thu, 19 Apr 2012 09:51:54 -0000 --Apple-Mail-6F00A1D5-1F63-482B-81FF-CA0EC9E77961 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Some of the use cases I have discussed with people also involve returning SA= ML tokens in the response for dealing with some existing systems. In principal if the RS is authenticated to the AS (perhaps with OAuth) then= the correct response format RS can be provided. =20 We need to decide what parts of this get standardized.=20 I am hoping for a interesting discussion on this at IIW that can inform an u= pdate to the Ping ID and used as a input for a eventual WG item. John B. Sent from my iPad On 2012-04-18, at 10:23 PM, Justin Richer wrote: > I think we might be crossing wires about input to the token introspection e= ndpoint vs. output from it. >=20 > In OpenID Connect, you send a JWT in, and get back a JSON object that repr= esents the Claims bit of the JWT. >=20 > In our implementation (and I think both Ping and AOL's), you send in an ar= bitrary token (with no proscribed format) and get back a JSON object with di= fferent pieces in it. Ours included a list of scopes and an expiration times= tamp, others did different things, like audience and issuer, as part of the r= eturn. >=20 > The point I was trying to make is that the information returned from the A= S-PR interface isn't necessarily embedded inside of the token used to call t= hat interface. In OpenID Connect, it is, and the CheckID endpoint just unwra= ps the JWT for you. In the larger case, what's really going on is that the P= R presents a token that it's not sure what it's good for and gets back somet= hing that answers that question. Since a JWT Claims section can be an arbitr= ary JSON object (for all intents and purposes), you could use a JWT as the o= utput of the introspection endpoint as well. >=20 > -- Justin >=20 > On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote: >> Hi Justin, >>=20 >> I refered to the data format used at the AS-PR interface. According to yo= ur description, you use JSON objects there. What data does such an object co= ntain? Is this any different from a JSON Web Token (leaving aside digital si= gnatures and encryption)? >>=20 >> regards, >> Torsten. >>=20 >> Am 18.04.2012 22:01, schrieb Justin Richer: >>> Not all implementations in the field that do this are using JWTs as the t= okens. Ours in particular used a random blob with no structured information i= n it. The endpoint returned a JSON object. >>>=20 >>> -- Justin >>>=20 >>> On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: >>>> Hi all, >>>>=20 >>>> is there enough experience in the field with such an interface to stand= ardize it? >>>>=20 >>>> I would expect such an endpoint to return the same payload, which is ca= rried in a JSON Web Token. So once we designed the JSON Web Tokens content, d= esigning the AS-PR interface could be the next logical step (after the next r= e-charting). >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>> Am 16.04.2012 21:04, schrieb Justin Richer: >>>>>=20 >>>>>>> OK, but with SWD and discovery off the table, can this now be >>>>>>> considered to be within that manageable number instead? >>>>>> We wanted to keep the # of WG items to approximately 5. Once we fini= sh >>>>>> some of these items and get them off our plate we could roll new item= s >>>>>> onto the plate, theoretically. >>>>>>=20 >>>>>=20 >>>>> That's definitely true going forward, but what I was saying is that th= e number of items under consideration is now down to 4, with SWD moving to t= he Apps group. I was proposing that the whole introspection endpoint and gen= eral AS-PR connection could be this group's fifth starting document. >>>>>=20 >>>>> -- Justin >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-6F00A1D5-1F63-482B-81FF-CA0EC9E77961 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MTkwOTUxNTlaMCMGCSqGSIb3DQEJBDEWBBT8k5pr donNj3QNzhulV/Y4zRu4/DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQBRPj/zfutIQLaok0vhngG0fgDhmGRn2qPeynCC xq46K3XCSFfQp3Dp38aXwb4ACuitWDVWGD7NZTLAFzYrbyXRXibYViNGwZwdOvTMsDcvze+T0C5O iv5d7/zpxQ88iumR0AKlbnCrFvKxe+mRlLsXa3ZA9yfn7d4xOMAreYxedwwFI4Fe+reNKpumBCeK 5cSs87d4VeiuiLlZMasU2imAufCItg76pOe1YBoYAeynpieLzZ/jUrnqqAcxPDBhfPGH/vxNqUC0 2TmYeEBZ2pvfgDlP0SxXrSMV2oIof+iB9sWmtdhLZX9Y+HFITlHeB3DDNOLksp90LCymGlZVZC4r AAAAAAAA --Apple-Mail-6F00A1D5-1F63-482B-81FF-CA0EC9E77961-- From wvengen+oauth2@nikhef.nl Thu Apr 19 04:32:02 2012 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 BD91721F85DF for ; Thu, 19 Apr 2012 04:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY4dPdNuLLm2 for ; Thu, 19 Apr 2012 04:32:02 -0700 (PDT) Received: from ambleve.nikhef.nl (ambleve.nikhef.nl [192.16.199.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3455B21F84E1 for ; Thu, 19 Apr 2012 04:31:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by ambleve.nikhef.nl (Postfix) with ESMTP id 59D557816D; Thu, 19 Apr 2012 13:31:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at nikhef.nl Received: from ambleve.nikhef.nl ([127.0.0.1]) by localhost (ambleve.nikhef.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RW5Q-dRYPx0J; Thu, 19 Apr 2012 13:31:44 +0200 (CEST) Received: from [192.16.192.241] (lap-241.nikhef.nl [192.16.192.241]) (Authenticated sender: wvengen) by ambleve.nikhef.nl (Postfix) with ESMTP id 201D37815C; Thu, 19 Apr 2012 13:31:44 +0200 (CEST) Message-ID: <4F8FF79F.9070705@nikhef.nl> Date: Thu, 19 Apr 2012 13:31:43 +0200 From: wvengen+oauth2@nikhef.nl User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Aaron Parecki References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Examples of structured tokens in the wild? 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: Thu, 19 Apr 2012 11:32:02 -0000 On 03/25/2012 07:51 PM, Aaron Parecki wrote: > If you have an example of an API that uses structured access tokens, I > would love some links to documentation or examples. I'm looking for some > examples of the types of information people put into structured tokens > for some OAuth 2 tutorials I'm writing. It would be great if these > examples were available in public services that I could poke at as well. Have you found some examples yet? - Willem From Adam.Lewis@motorolasolutions.com Thu Apr 19 07:43:58 2012 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 D3A4921F8674 for ; Thu, 19 Apr 2012 07:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN5sVaf0w3Xf for ; Thu, 19 Apr 2012 07:43:55 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9431121F860E for ; Thu, 19 Apr 2012 07:43:54 -0700 (PDT) Received: from mail35-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 14:43:53 +0000 Received: from mail35-am1 (localhost [127.0.0.1]) by mail35-am1-R.bigfish.com (Postfix) with ESMTP id F0E4F460358 for ; Thu, 19 Apr 2012 14:43:52 +0000 (UTC) X-SpamScore: -30 X-BigFish: VPS-30(zzbb2dI9371I542M98dKzz1202hzz1033IL8275dhz2fh2a8h683h839h944hd25h) X-Forefront-Antispam-Report: CIP:192.160.210.20; KIP:(null); UIP:(null); IPV:NLI; H:il27msg01.am.mot-solutions.com; RD:il27msg01.mot-solutions.com; EFVD:NLI Received-SPF: pass (mail35-am1: domain of motorolasolutions.com designates 192.160.210.20 as permitted sender) client-ip=192.160.210.20; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il27msg01.am.mot-solutions.com ; olutions.com ; Received: from mail35-am1 (localhost.localdomain [127.0.0.1]) by mail35-am1 (MessageSwitch) id 133484662327478_4476; Thu, 19 Apr 2012 14:43:43 +0000 (UTC) Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.250]) by mail35-am1.bigfish.com (Postfix) with ESMTP id F2A983A028C for ; Thu, 19 Apr 2012 14:43:42 +0000 (UTC) Received: from il27msg01.am.mot-solutions.com (192.160.210.20) by AM1EHSMHS020.bigfish.com (10.3.206.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 14:43:41 +0000 Received: from il27msg01.am.mot-solutions.com (ct11vts01.am.mot.com [10.177.16.159]) by il27msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3JEtOOI010472 for ; Thu, 19 Apr 2012 09:55:24 -0500 (CDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by il27msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3JEtNkw010466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Apr 2012 09:55:24 -0500 (CDT) Received: from mail27-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 14:43:37 +0000 Received: from mail27-am1 (localhost [127.0.0.1]) by mail27-am1-R.bigfish.com (Postfix) with ESMTP id 82181260185 for ; Thu, 19 Apr 2012 14:43:37 +0000 (UTC) Received: from mail27-am1 (localhost.localdomain [127.0.0.1]) by mail27-am1 (MessageSwitch) id 1334846599694721_10355; Thu, 19 Apr 2012 14:43:19 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.253]) by mail27-am1.bigfish.com (Postfix) with ESMTP id 130871E01EC; Thu, 19 Apr 2012 14:43:10 +0000 (UTC) Received: from BL2PRD0410HT001.namprd04.prod.outlook.com (157.56.240.85) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 14:43:08 +0000 Received: from BL2PRD0410MB363.namprd04.prod.outlook.com ([169.254.3.84]) by BL2PRD0410HT001.namprd04.prod.outlook.com ([10.255.99.36]) with mapi id 14.16.0143.004; Thu, 19 Apr 2012 14:43:07 +0000 From: Lewis Adam-CAL022 To: "wvengen+oauth2@nikhef.nl" , Aaron Parecki Thread-Topic: [OAUTH-WG] Examples of structured tokens in the wild? Thread-Index: AQHNHiAWqbGx+3H1LUuEKf7zCWu/aJaiMzuQ Date: Thu, 19 Apr 2012 14:43:06 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9085C14@BL2PRD0410MB363.namprd04.prod.outlook.com> References: <4F8FF79F.9070705@nikhef.nl> In-Reply-To: <4F8FF79F.9070705@nikhef.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.157.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0410HT001.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False;00160000;True;; X-OrganizationHeadersPreserved: BL2PRD0410HT001.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%NIKHEF.NL$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%PARECKI.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: OAuth WG Subject: Re: [OAUTH-WG] Examples of structured tokens in the wild? 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: Thu, 19 Apr 2012 14:43:59 -0000 I would find this useful as well. =20 I've been ramping up on OAuth and have found the lack of standardization of= access tokens very frustrating (structured vs. unstructured, if structured= then what type of structure, etc). Not being able to understand what type= of access tokens are being returned to the client from the token endpoint,= or not being able to understand the introspection of unstructured access t= okens between the RS and OAuth STS ... which seems to very entirely by impl= ementation, is a real issue (to my anyway :)) The OAuth spec talks about one AS being able to serve multiple RS, but in r= eality this might only be possible in a tightly controlled environment, whe= re the AS and each RS is of the same implementation. It would be nice to s= tandardize on the AS-to-RS interface ... it seems that some work is already= going on in that area. -adam -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of w= vengen+oauth2@nikhef.nl Sent: Thursday, April 19, 2012 6:32 AM To: Aaron Parecki Cc: OAuth WG Subject: Re: [OAUTH-WG] Examples of structured tokens in the wild? On 03/25/2012 07:51 PM, Aaron Parecki wrote: > If you have an example of an API that uses structured access tokens, I > would love some links to documentation or examples. I'm looking for some > examples of the types of information people put into structured tokens > for some OAuth 2 tutorials I'm writing. It would be great if these > examples were available in public services that I could poke at as well. Have you found some examples yet? - Willem _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Thu Apr 19 08:40:41 2012 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 23DF221F86D8 for ; Thu, 19 Apr 2012 08:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.24 X-Spam-Level: X-Spam-Status: No, score=-16.24 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rPOI-TlwPMg for ; Thu, 19 Apr 2012 08:40:36 -0700 (PDT) Received: from nm8-vm0.bullet.mail.ne1.yahoo.com (nm8-vm0.bullet.mail.ne1.yahoo.com [98.138.91.23]) by ietfa.amsl.com (Postfix) with SMTP id 841AB21F8653 for ; Thu, 19 Apr 2012 08:40:35 -0700 (PDT) Received: from [98.138.90.56] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 19 Apr 2012 15:40:33 -0000 Received: from [98.138.89.248] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 19 Apr 2012 15:40:33 -0000 Received: from [127.0.0.1] by omp1040.mail.ne1.yahoo.com with NNFMP; 19 Apr 2012 15:40:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 73206.16798.bm@omp1040.mail.ne1.yahoo.com Received: (qmail 40681 invoked by uid 60001); 19 Apr 2012 15:40:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334850032; bh=Li0d2hy7x85vZ24wsbKoHBzejJPSytFY2vLtBmo/i+M=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ets6m+vnLQElN+duxezlHRyrp4Aaxg5u6Z3wWsqir8/9a3K3RvXIjlnqtLeKXIuvzAdZL7ykRC0C82c2kb3bzkFD9FbuJ4fsiyFO5oYSQ3iB6Ii6FYnJxtZsQHFq3U9AKz4DmmjZvsgkpOWFxLv8k1qcvvyp84PLV0bL17+VpVQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ImrzMqAO/FOPQoAsuYwOnSvDW6vkRl/96NaYTGPJLPPgqGFan5d4ZaemAvabnTSb/Sus9js5sIESF9imSoEH2Li7CVr6OAFl0NYXdaNxScE9t/Wn6cqLhnz3aPkmAJUQoVnqjAdEAnp2kQU+EXYAAeGL1TYh+hCD1cqYK3KZ13s=; X-YMail-OSG: 7jC4GaUVM1ne560cLrNwBwnl9aKErKMChPdtKkHJFaLIN3f sLWzS0062B397Iena.TyIK_FuXeL.eka6iK0X8QMI4b6q3ZHt_spqxaLsDmK cTAgbuD5EOF8Dmmfwja0svjEz4FsYIGCEALKKLaFA59rnS9W7u7MvQtI.FYh SJjL6L14.crvODWU67cTa4nf2CJgPVTieFfWUSNqG0ficq12ztZwaEni94GW Y6c_dFhi1IO1MDwZf6.S1yQ4YKoewJJlUzAuqO1NwPuCtpLc4JhftD7dfV33 _Sunz4V4xdTh.FzTDdHdVSkDptwsQkEru1h_L.VuBH8ZKAlUzUXCTP7LIzQP f5FD7P8cQBWWTQyYzX5VW.BCHXL0MGejHcIf_Q02NnjqtNHyLP1NvfmlatO. NFzSWNGJaX97euOUR4uwwzfuSF1k2J3xQQCQLPc45fzWaPwZ4ryJGTdyVqBj yF4RHHI._ffKLrWi6dUun2a2E75MjexzjZ0jDBhDbuaeD0NQQN76W322WPQm nRHWcUpB0T2S0q785a_WrIkRi9QUxEAHltLM27x9VHidr1EfQY_z055iBjSH QgayGRL5DyChzUnucbA5et94iKRnJsbfiQJ.o0A8- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Thu, 19 Apr 2012 08:40:32 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <8F2CE30B-E2CA-4AFF-AAAC-6D1D98BA4400@uninett.no> Message-ID: <1334850032.31951.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Thu, 19 Apr 2012 08:40:32 -0700 (PDT) From: William Mills To: =?iso-8859-1?Q?Andreas_=C5kre_Solberg?= , "oauth@ietf.org" In-Reply-To: <8F2CE30B-E2CA-4AFF-AAAC-6D1D98BA4400@uninett.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-1843898353-1334850032=:31951" Subject: Re: [OAUTH-WG] Best-Practice for dealing with OAuth 2.0 Token expiration at the Consumer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 15:40:41 -0000 ---1238014912-1843898353-1334850032=:31951 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Scope having actual meaning to the client (you usage of 'offline' is what I= 'm looking at) is something you can define but is not something currently i= n the protocol.=0A=0AI think it's a simpler picture than you are painting:= =0A=0A1)=A0=A0=A0 You might get a hint with the expires_in value for when t= he token will expire.=A0 The client can refresh based on that.=0A2)=A0=A0= =A0 If you get an access token failure, then if you have a refresh token yo= u try to get a new access token.=0A3)=A0=A0=A0 If your refresh token fails = (not authorized) to get you a new access token, then you have to re-authent= icate.=A0 =0A=0A=0AHTTP temporary failures and such get retried.=0A=0AClien= ts basically have to support that logic flow.=0A=0A=0A=0A=0A>______________= __________________=0A> From: Andreas =C5kre Solberg =0A>To: oauth@ietf.org =0A>Sent: Thursday, April 19, 2012 1:29 AM=0A>S= ubject: [OAUTH-WG] Best-Practice for dealing with OAuth 2.0 Token expiratio= n at the Consumer=0A> =0A>Please give me feedback if I got anything wrong, = or if you have comments.=0A>=0A>https://rnd.feide.no/2012/04/19/best-practi= ce-for-dealing-with-oauth-2-0-token-expiration-at-the-consumer/=0A>=0A>Kind= regards,=0A>Andreas =C5kre Solberg=0A>UNINETT=0A>=0A>=0A>_________________= ______________________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>h= ttps://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A> ---1238014912-1843898353-1334850032=:31951 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Scope having actual meaning to the client (you usage of 'offline' is what= I'm looking at) is something you can define but is not something currently= in the protocol.

I thin= k it's a simpler picture than you are painting:

=
1)    You= might get a hint with the expires_in value for when the token will expire.=   The client can refresh based on that.
2)    If you get an acce= ss token failure, then if you have a refresh token you try to get a new acc= ess token.
3)    If you= r refresh token fails (not authorized) to get you a new access token, then = you have to re-authenticate. 

HTTP temporary failures and such g= et retried.

Clients basically have to support that logic flow.


From: Andreas =C5kre Solberg <andreas.solberg@= uninett.no>
To: oau= th@ietf.org
Sent: Thu= rsday, April 19, 2012 1:29 AM
Subject: [OAU= TH-WG] Best-Practice for dealing with OAuth 2.0 Token expiration at the Con= sumer

=0APlease give me feedback if I got anything w= rong, or if you have comments.

https://rnd.feide.no/2012/04/19/best-practice-for-= dealing-with-oauth-2-0-token-expiration-at-the-consumer/

Kind re= gards,
Andreas =C5kre Solberg
UNINETT


___________________= ____________________________
OAuth mailing list
OAuth@ietf.org
https:/= /www.ietf.org/mailman/listinfo/oauth


---1238014912-1843898353-1334850032=:31951-- From dick.hardt@gmail.com Thu Apr 19 08:52:22 2012 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 58F5621F8459; Thu, 19 Apr 2012 08:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URvRR8MmQGbm; Thu, 19 Apr 2012 08:52:18 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id DA19821F843F; Thu, 19 Apr 2012 08:52:17 -0700 (PDT) Received: by dady13 with SMTP id y13so15856257dad.27 for ; Thu, 19 Apr 2012 08:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=2qIykkL9j9WGZSMITfcXILEyjw+QGxwuMP0RkaimrWY=; b=Yy96WZ7Xw4CKZqmZcIwoVkR8zKxAQq4z4MUPQ95oiGjm4Q0tMO6TF3WhRRB2sb1UG8 SyJbL779Q/zZKUzv2dYTOnxItdVhKtujbIZwbdK/L4hVY/xyh1jPpCIGpaJeKdEOB3zP 9S7Sxf1VjR3bJ5BHEiNibE1tksDknGvPIFgL8vw8YpPlATZEzq4W96KUP835vyRDFi9A YZWErfBsJYofvpg0I5uQTvLF0yCEuxV29d+GMHudn4OjPeITUGBTrXbEUGUuShAc2Ief hU/cKWse82aXVfVDDynnx8av5w57SWlXl5CRucnjVkMCKk2cSd0Pq3vV+qOXWO5yDKMc FeAA== Received: by 10.68.72.138 with SMTP id d10mr5570379pbv.15.1334850737404; Thu, 19 Apr 2012 08:52:17 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id x1sm2567613pbp.50.2012.04.19.08.52.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 08:52:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_9C12D86B-A145-4A02-8079-077B2860BD29" From: Dick Hardt In-Reply-To: Date: Thu, 19 Apr 2012 08:52:13 -0700 Message-Id: <9B6B7851-5212-4313-88B5-DBBA7BC9BEDC@gmail.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> To: Blaine Cook X-Mailer: Apple Mail (2.1257) Cc: Tim Bray , "oauth@ietf.org WG" , apps-discuss@ietf.org Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 19 Apr 2012 15:52:22 -0000 --Apple-Mail=_9C12D86B-A145-4A02-8079-077B2860BD29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A couple months ago I was checking out what was up. The AOL and Yahoo = endpoints no longer worked. The Google one still did. On Apr 17, 2012, at 3:54 PM, Blaine Cook wrote: > That's a tricky question - maybe one google can help answer? There are = a bunch of projects using webfinger, including status.net, ostatus in = general, diaspora, unhosted, freedombox(?), and I'm sure others, but I = have no idea how that translates into actual users or profiles. >=20 > Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't = been much movement, I think due to the chicken and egg nature of = adoption around decentralized tools. >=20 > b. >=20 > On Apr 17, 2012 11:13 AM, "Tim Bray" wrote: > What is the deployment status of these two specs? Is either deployed > much at all? -T >=20 > On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy = wrote: > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell > >> Sent: Friday, April 13, 2012 9:23 AM > >> To: oauth@ietf.org WG > >> Cc: Apps Discuss > >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) > >> > >> So Hannes and Derek and I have been discussing this with the Apps = ADs > >> and Apps-area WG chairs. I've also read the docs now, and after all > >> that we've decided that this topic (what to do with swd and = webfinger) > >> is best handled in the apps area and not in the oauth WG. > >> > >> The logic for that is that 1) the two proposals are doing the same > >> thing and we don't want two different standards for that, b) this = is > >> not an oauth-specific thing nor is it a general security thing, and = c) > >> there is clearly already interest in the topic in the apps area so = its > >> reasonable for the oauth wg to use that when its ready. > >> > >> The appsawg chairs and apps ADs are ok with the work being done = there. > >> > >> So:- > >> > >> - I've asked the oauth chairs to take doing work on swd > >> out of the proposed new charter > >> - It may be that you want to add something saying that > >> oauth will use the results of work in the applications > >> area on a web discovery protocol as a basis for doing > >> the dynamic client registration work here > >> - Discussion of webfinger and swd should move over to > >> the apps-discuss list > >> - Note: this is not picking one or the other approach, > >> the plan is that the apps area will do any selection > >> needed and figure out the best starting point for a > >> standards-track RFC on web discovery and we'll use their > >> fine work for doing more with oauth. > > > > Thank you Stephen, I think. :-) > > > > So the discussion on apps-discuss now should be focused on which of = the two should be the basis for forward progress. I've placed both = documents in "Call for Adoption" state in the datatracker for appsawg. > > > > Let the games begin. > > > > -MSK > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > 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 --Apple-Mail=_9C12D86B-A145-4A02-8079-077B2860BD29 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii A couple months ago I was checking out what was up. The AOL and Yahoo endpoints no longer worked. The Google one still did.

On Apr 17, 2012, at 3:54 PM, Blaine Cook wrote:

That's a tricky question - maybe one google can help answer? There are a bunch of projects using webfinger, including status.net, ostatus in general, diaspora, unhosted, freedombox(?), and I'm sure others, but I have no idea how that translates into actual users or profiles.

Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't been much movement, I think due to the chicken and egg nature of adoption around decentralized tools.

b.

On Apr 17, 2012 11:13 AM, "Tim Bray" <tbray@textuality.com> wrote:
What is the deployment status of these two specs?  Is either deployed
much at all?  -T

On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy <msk@cloudmark.com> wrote:
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Stephen Farrell
>> Sent: Friday, April 13, 2012 9:23 AM
>> To: oauth@ietf.org WG
>> Cc: Apps Discuss
>> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
>>
>> So Hannes and Derek and I have been discussing this with the Apps ADs
>> and Apps-area WG chairs. I've also read the docs now, and after all
>> that we've decided that this topic (what to do with swd and webfinger)
>> is best handled in the apps area and not in the oauth WG.
>>
>> The logic for that is that 1) the two proposals are doing the same
>> thing and we don't want two different standards for that, b) this is
>> not an oauth-specific thing nor is it a general security thing, and c)
>> there is clearly already interest in the topic in the apps area so its
>> reasonable for the oauth wg to use that when its ready.
>>
>> The appsawg chairs and apps ADs are ok with the work being done there.
>>
>> So:-
>>
>> - I've asked the oauth chairs to take doing work on swd
>>   out of the proposed new charter
>> - It may be that you want to add something saying that
>>   oauth will use the results of work in the applications
>>   area on a web discovery protocol as a basis for doing
>>   the dynamic client registration work here
>> - Discussion of webfinger and swd should move over to
>>   the apps-discuss list
>> - Note: this is not picking one or the other approach,
>>   the plan is that the apps area will do any selection
>>   needed and figure out the best starting point for a
>>   standards-track RFC on web discovery and we'll use their
>>   fine work for doing more with oauth.
>
> Thank you Stephen, I think.  :-)
>
> So the discussion on apps-discuss now should be focused on which of the two should be the basis for forward progress.  I've placed both documents in "Call for Adoption" state in the datatracker for appsawg.
>
> Let the games begin.
>
> -MSK
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
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

--Apple-Mail=_9C12D86B-A145-4A02-8079-077B2860BD29-- From msk@cloudmark.com Thu Apr 19 09:32:21 2012 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 8C74A21F85D9 for ; Thu, 19 Apr 2012 09:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bewo88apyM6 for ; Thu, 19 Apr 2012 09:32:17 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7C321F85D1 for ; Thu, 19 Apr 2012 09:32:17 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id zsY61i0030as01C01sY6ik; Thu, 19 Apr 2012 09:32:06 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=RaES+iRv c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=uqmJ_63mYWYA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=wZ4MbW4DGOb2YpNH_mMA:9 a=CjuIK1q_8ugA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 09:32:06 -0700 From: "Murray S. Kucherawy" To: "oauth@ietf.org WG" , Apps Discuss Thread-Topic: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHAQiL3t2BLv+ykaRA2rPEeZvEJaiW2xg Date: Thu, 19 Apr 2012 16:32:06 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334853126; bh=eMMvh5Kly7HPtF+v+F34G6DX6Vs4TSArWlg6xhDRLTQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ICHjn2NYso8V8ZPTjsE+wsvrJv7O3Sd5lrXvuKaRK1jBX+Ondf52KansoZsR5cY53 tW7SD/t5SxkkiVptj01RqnNiwjPruw/ZRgc8klzWXiHDWfbmmro6APWfrpaAeaVhxZ j+L2QOx2M2uZEi20vr79d32tT+IcjfWwSKhk+xas= Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 19 Apr 2012 16:32:21 -0000 By all means people should correct me if they think I'm wrong about this, b= ut so far from monitoring the discussion there seems to be general support = for focusing on WebFinger and developing it to meet the needs of those who = have deployed SWD, versus the opposite. Does anyone want to argue the opposite? -MSK, appsawg co-chair From wmills@yahoo-inc.com Thu Apr 19 09:41:12 2012 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 55F8521F86EB for ; Thu, 19 Apr 2012 09:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.237 X-Spam-Level: X-Spam-Status: No, score=-17.237 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cO1Kg89HnLJ for ; Thu, 19 Apr 2012 09:41:08 -0700 (PDT) Received: from nm25.bullet.mail.bf1.yahoo.com (nm25.bullet.mail.bf1.yahoo.com [98.139.212.184]) by ietfa.amsl.com (Postfix) with SMTP id B8D5221F86D1 for ; Thu, 19 Apr 2012 09:41:06 -0700 (PDT) Received: from [98.139.214.32] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 19 Apr 2012 16:41:06 -0000 Received: from [98.139.212.224] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 19 Apr 2012 16:41:06 -0000 Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 19 Apr 2012 16:41:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 130269.74419.bm@omp1033.mail.bf1.yahoo.com Received: (qmail 57186 invoked by uid 60001); 19 Apr 2012 16:41:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334853665; bh=CaE44Le6VvGX7T+MpltDrsLIESJiSlHgWlFat5CkBYw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=G2PMZJSCiwZBlGb5xWDnr6KiMxmSLAw5w/5ynOGkt+ia1UB8pnKyn9mlYn29U/BcAfP2oF6/3BJT1RsYFparm8S++1undSun0jvELuaGDtXm5dFuk/6+gLj9CzZc3p4w0Ot/3qN7HlSgdlBBaskIIwFjBetXLJuh5FmpO34ziB8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=k0fWdUN5GjrjZCPNoBCHPBCEdf9JdQchYTH7nBSiL6EWmKiFEDop4SNmD3gs6GFlLjJBqQdGeTRM3yGNIbrueA60ck7pdXeZbLtK/1esTK7TkL2Yr0QoMpZFn+cgOCIWadzkYYjINEyEVZSertKKOiuNXdg4fxDklD0hrCOa+IQ=; X-YMail-OSG: HByvUqIVM1nbChYj.f_4wSABmYXGK7aOJIWFnsCUieJ.bf9 1HEaz3TVN80GW1dMNdXfYYl7WO.4fz3AJ1wEwrErhWBnJel_IQRj_VFksQ6Z EqMEV_RlXLPND_yQNKEgz8q.2yRy8SLA8_HnxxeRQZuxnoJmpgKfgwbFu5sm fl1IYaV2vCU5ShqgKglnBAT7kAdC8jl2z28HFzui7ZD1_n0jfhpst0WOnSl7 S_og6J5rGL3US5Y8hkDnND6KKNyx3PYNZyjLoynpZCgcl3yrOcIjDC1LmXAK yJirnl.Kctt96cYOtAFyHqnGlgSZ1w4p.TKkLEUdmlfaCbTu4L7Ml5UNp_pA TNq5MS2_.uERaaI6_Pi6HBiOPha44BZ5vFea2PDYXzQQqY18HwNHN.obtLLP Y4RYnk2kUSXQR8efVyT_uijkHdF0wBDz9WJy01o6iERXOTmEgTww- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Thu, 19 Apr 2012 09:41:05 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> Message-ID: <1334853665.6573.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 19 Apr 2012 09:41:05 -0700 (PDT) From: William Mills To: "Murray S. Kucherawy" , "oauth@ietf.org WG" , Apps Discuss In-Reply-To: <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-2129002210-1334853665=:6573" Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 16:41:12 -0000 --1458549034-2129002210-1334853665=:6573 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I would characterize it as two distinct camps, folks that think WF can be u= pdated to do what SWD (growing contingent I think) does and folks that are = invested in SWD.=A0 I haven't seen any movement between those two camps, sp= ecifically that the SWD folks think WF can in fact solve their problem if u= pdated.=0A=0A-bill=0A=0A=0A=0A=0A>________________________________=0A> From= : Murray S. Kucherawy =0A>To: "oauth@ietf.org WG" ; Apps Discuss =0A>Sent: Thursday, April = 19, 2012 9:32 AM=0A>Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. S= imple Web Discovery (SWD)=0A> =0A>By all means people should correct me if = they think I'm wrong about this, but so far from monitoring the discussion = there seems to be general support for focusing on WebFinger and developing = it to meet the needs of those who have deployed SWD, versus the opposite.= =0A>=0A>Does anyone want to argue the opposite?=0A>=0A>-MSK, appsawg co-cha= ir=0A>=0A>_______________________________________________=0A>OAuth mailing = list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>= =0A>=0A> --1458549034-2129002210-1334853665=:6573 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I would characterize it as two distinct camps, folks that think WF can be= updated to do what SWD (growing contingent I think) does and folks that ar= e invested in SWD.  I haven't seen any movement between those two camp= s, specifically that the SWD folks think WF can in fact solve their problem= if updated.

-bill

From: Mu= rray S. Kucherawy <msk@cloudmark.com>
To: "oauth@ietf.org WG" <oauth@ietf.org>; Apps Discuss= <apps-discuss@ietf.org>
S= ent: Thursday, April 19, 2012 9:32 AM
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finge= r vs. Simple Web Discovery (SWD)

=0ABy all means peo= ple should correct me if they think I'm wrong about this, but so far from m= onitoring the discussion there seems to be general support for focusing on = WebFinger and developing it to meet the needs of those who have deployed SW= D, versus the opposite.

Does anyone want to argue the opposite?
<= br>-MSK, appsawg co-chair

__________________________________________= _____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth


--1458549034-2129002210-1334853665=:6573-- From Michael.Jones@microsoft.com Thu Apr 19 09:48:56 2012 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 5E83721F8554; Thu, 19 Apr 2012 09:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.864 X-Spam-Level: X-Spam-Status: No, score=-3.864 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dzd7rV1X80j3; Thu, 19 Apr 2012 09:48:52 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 75BB221F8557; Thu, 19 Apr 2012 09:48:51 -0700 (PDT) Received: from mail79-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 16:48:51 +0000 Received: from mail79-ch1 (localhost [127.0.0.1]) by mail79-ch1-R.bigfish.com (Postfix) with ESMTP id 0FB4F4E05EB; Thu, 19 Apr 2012 16:48:51 +0000 (UTC) X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail79-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail79-ch1 (localhost.localdomain [127.0.0.1]) by mail79-ch1 (MessageSwitch) id 1334854128955743_11163; Thu, 19 Apr 2012 16:48:48 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail79-ch1.bigfish.com (Postfix) with ESMTP id E481E160046; Thu, 19 Apr 2012 16:48:48 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 16:48:47 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Thu, 19 Apr 2012 16:48:46 +0000 From: Mike Jones To: "Murray S. Kucherawy" , "oauth@ietf.org WG" , Apps Discuss Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHkoEkhvICdYO/UKyYU0IRCKljJaiWEsg Date: Thu, 19 Apr 2012 16:48:45 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 19 Apr 2012 16:48:56 -0000 There are two criteria that I would consider to be essential requirements f= or any resulting general-purpose discovery specification: 1. Being able to always discover per-user information with a single GET (m= inimizing user interface latency for mobile devices, etc.) 2. JSON should be required and it should be the only format required (simp= licity and ease of deployment/adoption) SWD already meets those requirements. If the resulting spec meets those re= quirements, it doesn't matter a lot whether we call it WebFinger or Simple = Web Discovery, but I believe that the requirements discussion is probably t= he most productive one to be having at this point - not the starting point = document. -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Thursday, April 19, 2012 9:32 AM To: oauth@ietf.org WG; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) By all means people should correct me if they think I'm wrong about this, b= ut so far from monitoring the discussion there seems to be general support = for focusing on WebFinger and developing it to meet the needs of those who = have deployed SWD, versus the opposite. Does anyone want to argue the opposite? -MSK, appsawg co-chair _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From melvincarvalho@gmail.com Thu Apr 19 09:54:11 2012 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 005F921F853D; Thu, 19 Apr 2012 09:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1yA+xiokqPH; Thu, 19 Apr 2012 09:54:06 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7628C21F8621; Thu, 19 Apr 2012 09:54:06 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2238508vcb.31 for ; Thu, 19 Apr 2012 09:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2xtqp7dvoLYhw3dFwgXP4LzL5KIkha366QNUmPh33Y4=; b=gc5Ca/sRrMqoeDiC8kbxzeUHNYgzAFAvT4/ZoeY7EyhyL2GdCK7wqQMbtMG/JfF+uy tbxwDUwzDuUFUh4I1zlKqd7KWGJ5SEBqTvsoYfGylIXr/ao6umAEvtuKyS4gXT+5WJpm aZYbbQ2KsqiVFzA4SOF5VlbMdjdv+YPtwjFzsAWIUiNuM1BNBPEgTtDvIbX9qYIhYr7y O0j2hXrPWe4WC1+flfHTYvYvfArh5vRxewTYXVtPPxXX4fPbmtF14tyPmG+MCUi57b62 oD+/87y0anx075OoyOFwIcW/QLwz10CDAM4HqsPoRCE69nMUCJPRdHMG6LUit4tkUKSp b1oA== MIME-Version: 1.0 Received: by 10.220.153.8 with SMTP id i8mr1487989vcw.73.1334854441552; Thu, 19 Apr 2012 09:54:01 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Thu, 19 Apr 2012 09:54:01 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Thu, 19 Apr 2012 18:54:01 +0200 Message-ID: From: Melvin Carvalho To: Mike Jones Content-Type: multipart/alternative; boundary=f46d043be068d0cb6c04be0b04f6 Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 19 Apr 2012 16:54:11 -0000 --f46d043be068d0cb6c04be0b04f6 Content-Type: text/plain; charset=ISO-8859-1 On 19 April 2012 18:48, Mike Jones wrote: > There are two criteria that I would consider to be essential requirements > for any resulting general-purpose discovery specification: > > 1. Being able to always discover per-user information with a single GET > (minimizing user interface latency for mobile devices, etc.) > > 2. JSON should be required and it should be the only format required > (simplicity and ease of deployment/adoption) > > SWD already meets those requirements. If the resulting spec meets those > requirements, it doesn't matter a lot whether we call it WebFinger or > Simple Web Discovery, but I believe that the requirements discussion is > probably the most productive one to be having at this point - not the > starting point document. > +1 -- Mike > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Murray S. Kucherawy > Sent: Thursday, April 19, 2012 9:32 AM > To: oauth@ietf.org WG; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > By all means people should correct me if they think I'm wrong about this, > but so far from monitoring the discussion there seems to be general support > for focusing on WebFinger and developing it to meet the needs of those who > have deployed SWD, versus the opposite. > > Does anyone want to argue the opposite? > > -MSK, appsawg co-chair > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d043be068d0cb6c04be0b04f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 19 April 2012 18:48, Mike Jones <Michael.Jon= es@microsoft.com> wrote:
There are two criteria that I would consider to be essential requirements f= or any resulting general-purpose discovery specification:

1. =A0Being able to always discover per-user information with a single GET = (minimizing user interface latency for mobile devices, etc.)

2. =A0JSON should be required and it should be the only format required (si= mplicity and ease of deployment/adoption)

SWD already meets those requirements. =A0If the resulting spec meets those = requirements, it doesn't matter a lot whether we call it WebFinger or S= imple Web Discovery, but I believe that the requirements discussion is prob= ably the most productive one to be having at this point - not the starting = point document.

+1

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 -- Mike

-----Original Message-----
From: apps-discuss-bounces= @ietf.org [mailto:apps= -discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 19, 2012 9:32 AM
To: oauth@= ietf.org WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

By all means people should co= rrect me if they think I'm wrong about this, but so far from monitoring= the discussion there seems to be general support for focusing on WebFinger= and developing it to meet the needs of those who have deployed SWD, versus= the opposite.

Does anyone want to argue the opposite?

-MSK, appsawg co-chair

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d043be068d0cb6c04be0b04f6-- From jpanzer@google.com Thu Apr 19 09:57:40 2012 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 BC66C21F863D for ; Thu, 19 Apr 2012 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JnBNpz6v6Cd for ; Thu, 19 Apr 2012 09:57:36 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 54CE721F861B for ; Thu, 19 Apr 2012 09:57:36 -0700 (PDT) Received: by qaea16 with SMTP id a16so2943qae.10 for ; Thu, 19 Apr 2012 09:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=1I6WPJfCXnc5r4Gt2kA3DpK6zu2VMaMoYS53PNMIRFA=; b=fXr0MAcRUhvAFkjI3clckPo7ZbgX6OoCkcanAYzlvX000cGW98UUuTM2AfXXQMKVF8 AVfMjho9rOiD6liMLEOk2/RJPUG7vwVQ+uX/yM6PxOTG64hMkolK0WQvpj6zsWDyF5Bf q7xWuiMCGQ01g/w1RyJerX7hVqAt1fwvOKC3jZ+TpHxBAq4FTlvnmaeCaCOdxLmOKEiA 7r/n36P1ui5fgbfZeWhMVCw+azqwFrDbSPFUheO4wEoWFC9emD2xYcc25D1yaFwNaKXg XLQPzN4rkvMwR2c/L1ekJGY3jN4zIMyJdW8RkTHV8YtI8eGl/OWvamn2MPIRm6rXLcfA 72rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=1I6WPJfCXnc5r4Gt2kA3DpK6zu2VMaMoYS53PNMIRFA=; b=e7hcOmt+N6ffkeYHj9nrxOfKxEJIZpj+amGc3uxP8FEs7bSoqlpVdOP7J5Q5qgPmSB HuMsoh6DcPeioA05d9Hh6Tn9fRQiTcTpT63llHR1hg5bpGgkpLtPqRUWAbBO1ydFvRaR fNz8kGQDHWaKrUUvLFe9GKQXMlOzlv5EyhkIXgsNNAOg2x31NwPB5Y0YH2yh5tkMlQQA xptpjc+iGInAOqbcRXGErC6oEkdpeeFddN5M70Er8EpwOGQlzSIGlUxjFpj2Q9Zu8GYl rrLmwIjCpmW9EXXihagsYGUvTzuTcx+QsactWMKGpKLbcW4jO2PyqqFVurVpjvNrzOSP 8oYQ== Received: by 10.224.116.5 with SMTP id k5mr4129410qaq.19.1334854655859; Thu, 19 Apr 2012 09:57:35 -0700 (PDT) Received: by 10.224.116.5 with SMTP id k5mr4129393qaq.19.1334854655725; Thu, 19 Apr 2012 09:57:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.22.133 with HTTP; Thu, 19 Apr 2012 09:57:15 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> From: John Panzer Date: Thu, 19 Apr 2012 09:57:15 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=20cf3074d21e94cf5b04be0b11bb X-System-Of-Record: true X-Gm-Message-State: ALoCoQnzHJJP/XWwOQxJTam3bSrjwFH6zdo+X1x3qfrm+iedGhtm4Hq03gIX2e++iVI0xbj/k6vSK1YJBCh9hsLH6Nqwe0rB0xxX29IHc5OkKiOPR4H1YJsFaeuB5Zcsx0494O/9i/Fd Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 19 Apr 2012 16:57:40 -0000 --20cf3074d21e94cf5b04be0b11bb Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 19, 2012 at 9:48 AM, Mike Jones wrote: > There are two criteria that I would consider to be essential requirements > for any resulting general-purpose discovery specification: > > 1. Being able to always discover per-user information with a single GET > (minimizing user interface latency for mobile devices, etc.) > Clarification: Does this requirement still allow HTTP redirects? (Meaning the server is in control of whether there is a single GET or not, basically, but can always ensure a single GET to minimize latency.) > > 2. JSON should be required and it should be the only format required > (simplicity and ease of deployment/adoption) > > I think nobody would argue against JSON support (certainly not me), I think few would argue against making it required. I personally would be okay with actually standardizing on JSON as the only required format as it doesn't preclude anyone from supporting other formats if they wish (for legacy/etc. reasons). > SWD already meets those requirements. If the resulting spec meets those > requirements, it doesn't matter a lot whether we call it WebFinger or > Simple Web Discovery, but I believe that the requirements discussion is > probably the most productive one to be having at this point - not the > starting point document. > > -- Mike > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Murray S. Kucherawy > Sent: Thursday, April 19, 2012 9:32 AM > To: oauth@ietf.org WG; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > By all means people should correct me if they think I'm wrong about this, > but so far from monitoring the discussion there seems to be general support > for focusing on WebFinger and developing it to meet the needs of those who > have deployed SWD, versus the opposite. > > Does anyone want to argue the opposite? > > -MSK, appsawg co-chair > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --20cf3074d21e94cf5b04be0b11bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 19, 2012 at 9:48 AM, Mike Jones <Michael.Jo= nes@microsoft.com> wrote:
There are two criteria that I would consider to be essential requirements f= or any resulting general-purpose discovery specification:

1. =A0Being able to always discover per-user information with a single GET = (minimizing user interface latency for mobile devices, etc.)

Clarification: =A0Does this requirement still allow H= TTP redirects? =A0(Meaning the server is in control of whether there is a s= ingle GET or not, basically, but can always ensure a single GET to minimize= latency.)
=A0

2. =A0JSON should be required and it should be the only format required (si= mplicity and ease of deployment/adoption)


I think nobody would argue against JSO= N support (certainly not me), I think few would argue against making it req= uired. =A0I personally would be okay with actually standardizing on JSON as= the only required format as it doesn't preclude anyone from supporting= other formats if they wish (for legacy/etc. reasons).
=A0
SWD already meets those requirements. =A0If the resulting spec meets those = requirements, it doesn't matter a lot whether we call it WebFinger or S= imple Web Discovery, but I believe that the requirements discussion is prob= ably the most productive one to be having at this point - not the starting = point document.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike

-----Original Message-----
From: apps-discuss-bounces= @ietf.org [mailto:apps= -discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 19, 2012 9:32 AM
To: oauth@= ietf.org WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

By all means people should co= rrect me if they think I'm wrong about this, but so far from monitoring= the discussion there seems to be general support for focusing on WebFinger= and developing it to meet the needs of those who have deployed SWD, versus= the opposite.

Does anyone want to argue the opposite?

-MSK, appsawg co-chair

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________= ________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--20cf3074d21e94cf5b04be0b11bb-- From msk@cloudmark.com Thu Apr 19 10:02:26 2012 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 0E8B921F8643 for ; Thu, 19 Apr 2012 10:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m2-tQoTdsf5 for ; Thu, 19 Apr 2012 10:02:21 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id B0A9421F8633 for ; Thu, 19 Apr 2012 10:02:21 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id zt2f1i0010ZaKgw01t2fmj; Thu, 19 Apr 2012 10:02:39 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=fNu7LOme c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=Vhm4rtfK4QIA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=yMhMjlubAAAA:8 a=zwOUNh7tUOjHoIInj9UA:9 a=szDEiDA6S8twofwXI_MA:7 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=-AOE9ft50oIA:10 a=SSmOFEACAAAA:8 a=fjQxKX33D8qoFgcPYFMA:9 a=-XqMH-EH7er2g2nBGhQA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 10:02:20 -0700 From: "Murray S. Kucherawy" To: "oauth@ietf.org WG" , Apps Discuss Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHk0Wy2pvmKYCykKGt3/ABzAPspaiX67Q Date: Thu, 19 Apr 2012 17:02:20 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280FAD6C@exch-mbx901.corp.cloudmark.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280FAD6Cexchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334854959; bh=K76ordO5IAF/WLMQEx42qysVJguy3kaI8hJMkdSKcH0=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=PBdTvaa3J0bL9rXTvBA+INWRaXmWA/IiwqlqYrB0tDPhz+Veo4CVQNZ3EYF1MUSnt 9jh2y/XI7BOmOqjq3LMmMBfOaj5gBkCCbOqLXEB2rcyZZ0gAR4FJGvXIfW90bkmYcN dju76oD7Wgrac93TOQtDxGRuxqHNnCIB7WPNQ9Wk= Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 19 Apr 2012 17:02:26 -0000 --_000_9452079D1A51524AA5749AD23E0039280FAD6Cexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fair enough, carry on. :) From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Thursday, April 19, 2012 9:54 AM To: Mike Jones Cc: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) On 19 April 2012 18:48, Mike Jones > wrote: There are two criteria that I would consider to be essential requirements f= or any resulting general-purpose discovery specification: 1. Being able to always discover per-user information with a single GET (m= inimizing user interface latency for mobile devices, etc.) 2. JSON should be required and it should be the only format required (simp= licity and ease of deployment/adoption) SWD already meets those requirements. If the resulting spec meets those re= quirements, it doesn't matter a lot whether we call it WebFinger or Simple = Web Discovery, but I believe that the requirements discussion is probably t= he most productive one to be having at this point - not the starting point = document. +1 -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org]= On Behalf Of Murray S. Kucherawy Sent: Thursday, April 19, 2012 9:32 AM To: oauth@ietf.org WG; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) By all means people should correct me if they think I'm wrong about this, b= ut so far from monitoring the discussion there seems to be general support = for focusing on WebFinger and developing it to meet the needs of those who = have deployed SWD, versus the opposite. Does anyone want to argue the opposite? -MSK, appsawg co-chair _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_9452079D1A51524AA5749AD23E0039280FAD6Cexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fair enough, carry on.&nb= sp; J

 <= /p>

From: Melvin C= arvalho [mailto:melvincarvalho@gmail.com]
Sent: Thursday, April 19, 2012 9:54 AM
To: Mike Jones
Cc: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Dis= covery (SWD)

 

 

On 19 April 2012 18:48, Mike Jones <Michael.Jones@microsoft.com> wrote= :

There are two criteria that I would consider to be e= ssential requirements for any resulting general-purpose discovery specifica= tion:

1.  Being able to always discover per-user information with a single G= ET (minimizing user interface latency for mobile devices, etc.)

2.  JSON should be required and it should be the only format required = (simplicity and ease of deployment/adoption)

SWD already meets those requirements.  If the resulting spec meets tho= se requirements, it doesn't matter a lot whether we call it WebFinger or Si= mple Web Discovery, but I believe that the requirements discussion is proba= bly the most productive one to be having at this point - not the starting point document.


+1

                    &nbs= p;          -- Mike


-----Original Message-----
From: apps-discuss-bounces= @ietf.org [mailto:apps= -discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 19, 2012 9:32 AM

To: oauth@ietf.org WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

By all means people should correct me if they think = I'm wrong about this, but so far from monitoring the discussion there seems= to be general support for focusing on WebFinger and developing it to meet = the needs of those who have deployed SWD, versus the opposite.

Does anyone want to argue the opposite?

-MSK, appsawg co-chair

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

 

--_000_9452079D1A51524AA5749AD23E0039280FAD6Cexchmbx901corpclo_-- From igor.faynberg@alcatel-lucent.com Thu Apr 19 11:02:53 2012 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 B6B0721F85C5 for ; Thu, 19 Apr 2012 11:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.141 X-Spam-Level: X-Spam-Status: No, score=-9.141 tagged_above=-999 required=5 tests=[AWL=1.458, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SY7L7FaPLpD for ; Thu, 19 Apr 2012 11:02:50 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DEBC721F85BB for ; Thu, 19 Apr 2012 11:02:49 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q3JI2nn1003664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Apr 2012 13:02:49 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3JI2mQK023552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 19 Apr 2012 13:02:48 -0500 Received: from [135.244.32.242] (faynberg.lra.lucent.com [135.244.32.242]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3JI2mWq010391; Thu, 19 Apr 2012 13:02:48 -0500 (CDT) Message-ID: <4F905348.9090505@alcatel-lucent.com> Date: Thu, 19 Apr 2012 14:02:48 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 18:02:53 -0000 +1 on the requirements. On 4/19/2012 12:48 PM, Mike Jones wrote: > There are two criteria that I would consider to be essential requirements for any resulting general-purpose discovery specification: > > 1. Being able to always discover per-user information with a single GET (minimizing user interface latency for mobile devices, etc.) > > 2. JSON should be required and it should be the only format required (simplicity and ease of deployment/adoption) > > SWD already meets those requirements. If the resulting spec meets those requirements, it doesn't matter a lot whether we call it WebFinger or Simple Web Discovery, but I believe that the requirements discussion is probably the most productive one to be having at this point - not the starting point document. > > -- Mike > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy > Sent: Thursday, April 19, 2012 9:32 AM > To: oauth@ietf.org WG; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) > > By all means people should correct me if they think I'm wrong about this, but so far from monitoring the discussion there seems to be general support for focusing on WebFinger and developing it to meet the needs of those who have deployed SWD, versus the opposite. > > Does anyone want to argue the opposite? > > -MSK, appsawg co-chair > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Thu Apr 19 11:23:01 2012 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 1ECEA21F8653; Thu, 19 Apr 2012 11:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Gx9DMhiO3H0; Thu, 19 Apr 2012 11:23:00 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id DC93A21F863F; Thu, 19 Apr 2012 11:22:59 -0700 (PDT) Received: from mail125-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 18:22:59 +0000 Received: from mail125-ch1 (localhost [127.0.0.1]) by mail125-ch1-R.bigfish.com (Postfix) with ESMTP id 43A3F1E0202; Thu, 19 Apr 2012 18:22:59 +0000 (UTC) X-SpamScore: -30 X-BigFish: VS-30(zzbb2dI9371I542Mc85dh98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail125-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail125-ch1 (localhost.localdomain [127.0.0.1]) by mail125-ch1 (MessageSwitch) id 1334859777484032_21123; Thu, 19 Apr 2012 18:22:57 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail125-ch1.bigfish.com (Postfix) with ESMTP id 66DAF6005B; Thu, 19 Apr 2012 18:22:57 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 18:22:56 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Thu, 19 Apr 2012 18:22:46 +0000 From: Mike Jones To: John Panzer Thread-Topic: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHk5rJwvCScwa5U+4IAklxXbdk5aidjmP Date: Thu, 19 Apr 2012 18:22:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366490C03@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366490C03TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 19 Apr 2012 18:23:01 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366490C03TK5EX14MBXC284r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree that redirects need to be followed, when used. -- Mike ________________________________ From: John Panzer Sent: 4/19/2012 7:04 PM To: Mike Jones Cc: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery = (SWD) On Thu, Apr 19, 2012 at 9:48 AM, Mike Jones > wrote: There are two criteria that I would consider to be essential requirements f= or any resulting general-purpose discovery specification: 1. Being able to always discover per-user information with a single GET (m= inimizing user interface latency for mobile devices, etc.) Clarification: Does this requirement still allow HTTP redirects? (Meaning= the server is in control of whether there is a single GET or not, basicall= y, but can always ensure a single GET to minimize latency.) 2. JSON should be required and it should be the only format required (simp= licity and ease of deployment/adoption) I think nobody would argue against JSON support (certainly not me), I think= few would argue against making it required. I personally would be okay wi= th actually standardizing on JSON as the only required format as it doesn't= preclude anyone from supporting other formats if they wish (for legacy/etc= . reasons). SWD already meets those requirements. If the resulting spec meets those re= quirements, it doesn't matter a lot whether we call it WebFinger or Simple = Web Discovery, but I believe that the requirements discussion is probably t= he most productive one to be having at this point - not the starting point = document. -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org]= On Behalf Of Murray S. Kucherawy Sent: Thursday, April 19, 2012 9:32 AM To: oauth@ietf.org WG; Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) By all means people should correct me if they think I'm wrong about this, b= ut so far from monitoring the discussion there seems to be general support = for focusing on WebFinger and developing it to meet the needs of those who = have deployed SWD, versus the opposite. Does anyone want to argue the opposite? -MSK, appsawg co-chair _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394366490C03TK5EX14MBXC284r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree that = redirects need to be followed, when used.

-- Mike
From: John P= anzer
Sent: 4/19/2= 012 7:04 PM
To: Mike J= ones
Cc: Murray= S. Kucherawy; oauth@ietf.org WG; Apps Discuss
Subject: Re: [O= AUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
On Thu, Apr 19, 2012 at 9:48 AM, Mike Jones <Michael.Jones@microsoft.= com> wrote:
There are two criteria that I would consider to be essential requirements f= or any resulting general-purpose discovery specification:

1.  Being able to always discover per-user information with a single G= ET (minimizing user interface latency for mobile devices, etc.)

Clarification:  Does this requirement still allow HTTP redirects?=  (Meaning the server is in control of whether there is a single GET o= r not, basically, but can always ensure a single GET to minimize latency.)<= /div>
 

2.  JSON should be required and it should be the only format required = (simplicity and ease of deployment/adoption)


I think nobody would argue against JSON support (certainly not me), I = think few would argue against making it required.  I personally would = be okay with actually standardizing on JSON as the only required format as = it doesn't preclude anyone from supporting other formats if they wish (for legacy/etc. reasons).
 
SWD already meets those requirements.  If the resulting spec meets tho= se requirements, it doesn't matter a lot whether we call it WebFinger or Si= mple Web Discovery, but I believe that the requirements discussion is proba= bly the most productive one to be having at this point - not the starting point document.

                     = ;          -- Mike

-----Original Message-----
From: apps-discuss-bounces= @ietf.org [mailto:apps= -discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, April 19, 2012 9:32 AM
To: oauth@ietf.o= rg WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD)

By all means people should correct me if they think I'm w= rong about this, but so far from monitoring the discussion there seems to b= e general support for focusing on WebFinger and developing it to meet the n= eeds of those who have deployed SWD, versus the opposite.

Does anyone want to argue the opposite?

-MSK, appsawg co-chair

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B168042967394366490C03TK5EX14MBXC284r_-- From eran@hueniverse.com Thu Apr 19 11:26:36 2012 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 DE6DE11E8074; Thu, 19 Apr 2012 11:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dws1sgesNX7B; Thu, 19 Apr 2012 11:26:36 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1060811E8073; Thu, 19 Apr 2012 11:26:36 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id zuSb1i00A0CJzpC01uSbCB; Thu, 19 Apr 2012 11:26:35 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Thu, 19 Apr 2012 11:26:35 -0700 From: Eran Hammer To: Mike Jones , "Murray S. Kucherawy" , "oauth@ietf.org WG" , Apps Discuss Thread-Topic: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHkxUamxtxNaeJEOwZxtbGF43j5aidV7Q Date: Thu, 19 Apr 2012 18:26:34 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FF1C6A@P3PWEX2MB008.ex2.secureserver.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.163.44.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 19 Apr 2012 18:26:37 -0000 #1 as John Panzer identified, allowing the server to control its deployment= and supporting HTTP redirects is critical. #2 JSON is better, which one is required is less of on issue but more of a = best practices item. I'll add: * Highly cachable * Optimize for large providers, reducing the need to make repeated requests= when the information is mostly following a template on the server side * Ability to provide discovery on resources, not users or any other subset = (emails, etc.) * Security agnostic - leave it to HTTP, TLS, OAuth, etc. * HTTP compliant - doesn't invent it's own rediretion menthods or custom he= aders, etc. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Mike Jones > Sent: Thursday, April 19, 2012 9:49 AM > To: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss > Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web > Discovery (SWD) >=20 > There are two criteria that I would consider to be essential requirements= for > any resulting general-purpose discovery specification: >=20 > 1. Being able to always discover per-user information with a single GET > (minimizing user interface latency for mobile devices, etc.) >=20 > 2. JSON should be required and it should be the only format required > (simplicity and ease of deployment/adoption) >=20 > SWD already meets those requirements. If the resulting spec meets those > requirements, it doesn't matter a lot whether we call it WebFinger or Sim= ple > Web Discovery, but I believe that the requirements discussion is probably > the most productive one to be having at this point - not the starting poi= nt > document. >=20 > -- Mike >=20 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Murray S. Kucherawy > Sent: Thursday, April 19, 2012 9:32 AM > To: oauth@ietf.org WG; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery (SWD) >=20 > By all means people should correct me if they think I'm wrong about this,= but > so far from monitoring the discussion there seems to be general support f= or > focusing on WebFinger and developing it to meet the needs of those who > have deployed SWD, versus the opposite. >=20 > Does anyone want to argue the opposite? >=20 > -MSK, appsawg co-chair >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Thu Apr 19 11:31:18 2012 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 65D7011E80B6 for ; Thu, 19 Apr 2012 11:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR4DgJ1xEyDm for ; Thu, 19 Apr 2012 11:31:17 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by ietfa.amsl.com (Postfix) with ESMTP id 70C9111E808A for ; Thu, 19 Apr 2012 11:31:17 -0700 (PDT) Received: from [79.253.16.77] (helo=[192.168.71.36]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SKw8Q-0004x3-V1; Thu, 19 Apr 2012 20:31:15 +0200 Message-ID: <4F9059F5.1050705@lodderstedt.net> Date: Thu, 19 Apr 2012 20:31:17 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Justin Richer References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F88713C.6070309@mitre.org> <4F8C6D43.2030701@mitre.org> <4F8F1B9F.1040302@lodderstedt.net> <4F8F1D94.4090208@mitre.org> <4F8F1F9C.7020008@lodderstedt.net> <4F8F22C4.6000900@mitre.org> In-Reply-To: <4F8F22C4.6000900@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: Derek Atkins , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend) 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: Thu, 19 Apr 2012 18:31:18 -0000 Hi Justin, In my opinion, the OpenID Connect introspection/checkid endpoint is a convenience function for clients (not resource servers) unable to decrypt id tokens and validate their signatures. I'm not convinced this function is needed, that's why I proposed to drop it. The AS-PR endpoint servers a different purpose, as it allows to implement handle-based token designs. The AS just creates simple token (e.g. a random number), which is very small and does not need to be encrypted or signed. This might result in simple designs. On the other hand, the PR needs to lookup authz data as part of the request implementation, which might have a negative impact on performance and scalability. That's where self-contained tokens, such as JWT have their merits. I don't think one would combine self-contained tokens with an AS-PR endpoint. Or is this the case in any existing implementations? The point I wanted to make is: no matter how the resource server acquires authz data (as token content/JWT or via request to another AS-PR endpoint), the authz data will be the same. And as part of the JWT standardization, we will identify this data and specify a JSON format to represent it. The same representation could be used at the AS-PR endpoint as well. regards, Torsten. Am 18.04.2012 22:23, schrieb Justin Richer: > I think we might be crossing wires about input to the token > introspection endpoint vs. output from it. > > In OpenID Connect, you send a JWT in, and get back a JSON object that > represents the Claims bit of the JWT. > > In our implementation (and I think both Ping and AOL's), you send in > an arbitrary token (with no proscribed format) and get back a JSON > object with different pieces in it. Ours included a list of scopes and > an expiration timestamp, others did different things, like audience > and issuer, as part of the return. > > The point I was trying to make is that the information returned from > the AS-PR interface isn't necessarily embedded inside of the token > used to call that interface. In OpenID Connect, it is, and the CheckID > endpoint just unwraps the JWT for you. In the larger case, what's > really going on is that the PR presents a token that it's not sure > what it's good for and gets back something that answers that question. > Since a JWT Claims section can be an arbitrary JSON object (for all > intents and purposes), you could use a JWT as the output of the > introspection endpoint as well. > > -- Justin > > On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote: >> Hi Justin, >> >> I refered to the data format used at the AS-PR interface. According >> to your description, you use JSON objects there. What data does such >> an object contain? Is this any different from a JSON Web Token >> (leaving aside digital signatures and encryption)? >> >> regards, >> Torsten. >> >> Am 18.04.2012 22:01, schrieb Justin Richer: >>> Not all implementations in the field that do this are using JWTs as >>> the tokens. Ours in particular used a random blob with no structured >>> information in it. The endpoint returned a JSON object. >>> >>> -- Justin >>> >>> On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: >>>> Hi all, >>>> >>>> is there enough experience in the field with such an interface to >>>> standardize it? >>>> >>>> I would expect such an endpoint to return the same payload, which >>>> is carried in a JSON Web Token. So once we designed the JSON Web >>>> Tokens content, designing the AS-PR interface could be the next >>>> logical step (after the next re-charting). >>>> >>>> regards, >>>> Torsten. >>>> >>>> Am 16.04.2012 21:04, schrieb Justin Richer: >>>>> >>>>>>> OK, but with SWD and discovery off the table, can this now be >>>>>>> considered to be within that manageable number instead? >>>>>> We wanted to keep the # of WG items to approximately 5. Once we >>>>>> finish >>>>>> some of these items and get them off our plate we could roll new >>>>>> items >>>>>> onto the plate, theoretically. >>>>>> >>>>> >>>>> That's definitely true going forward, but what I was saying is >>>>> that the number of items under consideration is now down to 4, >>>>> with SWD moving to the Apps group. I was proposing that the whole >>>>> introspection endpoint and general AS-PR connection could be this >>>>> group's fifth starting document. >>>>> >>>>> -- Justin >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> > From torsten@lodderstedt.net Thu Apr 19 11:40:06 2012 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 EBF7E21F84F3; Thu, 19 Apr 2012 11:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtgXW4v+64LR; Thu, 19 Apr 2012 11:40:05 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6616E21F844C; Thu, 19 Apr 2012 11:40:05 -0700 (PDT) Received: from [79.253.16.77] (helo=[192.168.71.36]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SKwGx-0000Y9-PP; Thu, 19 Apr 2012 20:40:03 +0200 Message-ID: <4F905C06.6070201@lodderstedt.net> Date: Thu, 19 Apr 2012 20:40:06 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Mike Jones References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 19 Apr 2012 18:40:06 -0000 Hi Mike, Am 19.04.2012 18:48, schrieb Mike Jones: > There are two criteria that I would consider to be essential requirements for any resulting general-purpose discovery specification: > > 1. Being able to always discover per-user information with a single GET (minimizing user interface latency for mobile devices, etc.) Is this a requirement from an OpenID Connect perspective? I'm asking because I think a user is not always the starting point of a discovery process in the more general OAuth case. In my opinion there is a need to discover (1) the authorization server a particular resource server relies on ("www.example.com/webdav" --> "as.example.com" and (2) the properties of this authz server ("as.example.com" --> tokens, authz, revocation endpoints, grant types, ...). How would this work with SWD or WebFinger? regards, Torsten. From melvincarvalho@gmail.com Thu Apr 19 14:12:25 2012 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 C0DCF21F858B; Thu, 19 Apr 2012 14:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2R5X0DUdv5R; Thu, 19 Apr 2012 14:12:24 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47DD621F84C4; Thu, 19 Apr 2012 14:12:24 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2432117vcb.31 for ; Thu, 19 Apr 2012 14:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tk1+OiwgYZwl+p4Q2V5c4YufcGFTH2syCwDftsiR2c0=; b=l9Z5VSaY/C+m9Oph/MV1AR4A4eP5s9LjxJXa/EsOLN1N0sbzevTcPLbIUkim8VBGPU pAIj8BJuhDJUzy2auwrHA75qAU+s9aNNwq46P3QiUE76hRXzYTmV4p5GuMQ9R4C5MjoB fCCEB02qarIyJFEFEXxcvEGPmqDM0x79a0lfRo2gpvrferU6COwFGe+JMBgcjtlVd20w JwLk6vc4OtOAzYnWwqU/59BQ5eX52qvgY7L2QPtiIRvjpyvSDxCmVDwvHuokYeLIQmQz 3wZYTGVgInEn/WomeC5OCzw5lWO4w9FtVaayD4gjpX14rL5lIGHW3X9fDV4EpFZUJZFu UQrw== MIME-Version: 1.0 Received: by 10.220.150.134 with SMTP id y6mr1952997vcv.43.1334869943741; Thu, 19 Apr 2012 14:12:23 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Thu, 19 Apr 2012 14:12:23 -0700 (PDT) In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FF1C6A@P3PWEX2MB008.ex2.secureserver.net> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FF1C6A@P3PWEX2MB008.ex2.secureserver.net> Date: Thu, 19 Apr 2012 23:12:23 +0200 Message-ID: From: Melvin Carvalho To: Eran Hammer Content-Type: multipart/alternative; boundary=f46d04389363d16d1604be0ea0a8 Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 19 Apr 2012 21:12:26 -0000 --f46d04389363d16d1604be0ea0a8 Content-Type: text/plain; charset=ISO-8859-1 On 19 April 2012 20:26, Eran Hammer wrote: > #1 as John Panzer identified, allowing the server to control its > deployment and supporting HTTP redirects is critical. > +1 > #2 JSON is better, which one is required is less of on issue but more of a > best practices item. > Happy with this comment, and a +1 for JSON only > > I'll add: > > * Highly cachable > +1 tho I think most CSN dont cache a 303 redirect > * Optimize for large providers, reducing the need to make repeated > requests when the information is mostly following a template on the server > side > +1 > * Ability to provide discovery on resources, not users or any other subset > (emails, etc.) > There's a subtlety here and that's the difference in HTML between "rel" and "rev". A forward or reverse lookup. Forward is a natural way to look things up, eg you give a URL and you get a document. But something like google search is actually a reverse index, you give it words and you get back URLs for documents. Initially hard to get your head round, but in practice can be incredibly practical and useful. Given a triple such as (subject verb object) email Is your lookup based on the subject (WF) or the object (SWF)? If subject then you need something there. However, it need not be an acct: URI It could be a URN eg urn:acct:user@host (no new uri scheme needed) it could be a relative URI such as <#> (which facebook do) This indicates a pointer to the top of the document It can even be blank <> The so-called 'blank node' in the linked data world, but then you're more reliant on a query language, such as SPARQL. I'm sure I havent covered every possibility. OR you can key off the Object email then return all key values assoicated with which would be in the @subject position in the case of XRD/JRD or the @id position in the case of something like JSON LD It's quite confusing but essentially you are asking two very different things: 1) Give me all information where the subject is acct:user@host Which also means having to create a mapping, and educating every system what the subject of their email (or xmpp/sip/tel/twitter account) should be. A potentially big task. Im not saying it's wrong, but IMHO this is potentially big enough to fill a whole other standards document in itself. or 2) Give me all information for the user with email mailto:user@host Non disruptive I'm sorry If i have not explained this very well, but the difference between rev and rel confuses a lot of confusion in HTML, and that's essentially the subtlety here (forward vs reverse lookup) > * Security agnostic - leave it to HTTP, TLS, OAuth, etc. > +1 > * HTTP compliant - doesn't invent it's own rediretion menthods or custom > headers, etc. > +1 > > EH > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Mike Jones > > Sent: Thursday, April 19, 2012 9:49 AM > > To: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss > > Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web > > Discovery (SWD) > > > > There are two criteria that I would consider to be essential > requirements for > > any resulting general-purpose discovery specification: > > > > 1. Being able to always discover per-user information with a single GET > > (minimizing user interface latency for mobile devices, etc.) > > > > 2. JSON should be required and it should be the only format required > > (simplicity and ease of deployment/adoption) > > > > SWD already meets those requirements. If the resulting spec meets those > > requirements, it doesn't matter a lot whether we call it WebFinger or > Simple > > Web Discovery, but I believe that the requirements discussion is probably > > the most productive one to be having at this point - not the starting > point > > document. > > > > -- Mike > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of Murray S. Kucherawy > > Sent: Thursday, April 19, 2012 9:32 AM > > To: oauth@ietf.org WG; Apps Discuss > > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > > Discovery (SWD) > > > > By all means people should correct me if they think I'm wrong about > this, but > > so far from monitoring the discussion there seems to be general support > for > > focusing on WebFinger and developing it to meet the needs of those who > > have deployed SWD, versus the opposite. > > > > Does anyone want to argue the opposite? > > > > -MSK, appsawg co-chair > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04389363d16d1604be0ea0a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 19 April 2012 20:26, Eran Hammer <eran@hueniverse.co= m> wrote:
#1 as John Panzer identified, allowing the server to control its deployment= and supporting HTTP redirects is critical.

+1
= =A0
#2 JSON is better, which one is required is less of on issue but more of a = best practices item.

Happy with this comment, and = a +1 for JSON only
=A0

I'll add:

* Highly cachable

+1 tho I think most CSN dont cac= he a 303 redirect
=A0
* Optimize for large providers, reducing the need to make repeated requests= when the information is mostly following a template on the server side
=

+1
=A0
* Ability to provide discovery on resources, not users or any other subset = (emails, etc.)

There's a subtlety here and tha= t's the difference in HTML between "rel" and "rev".= =A0

A forward or reverse lookup.=A0 Forward is a natural way to look things= up, eg you give a URL and you get a document.=A0 But something like google= search is actually a reverse index, you give it words and you get back URL= s for documents.=A0 Initially hard to get your head round, but in practice = can be incredibly practical and useful.

Given a triple such as (subject verb object)

<acct:user@host&= gt;=A0 email=A0 <mailto:user@host>
Is your lookup based on the subject (WF) or the object (SWF)?=A0
=
If subject then you need something there.=A0 However, it need not be an acc= t: URI

It could be a URN eg

urn:acct:user@host=A0 (no new uri= scheme needed)

it could be a relative URI such as

<#>= =A0 (which facebook do)

This indicates a pointer to the top of the document

It can even = be blank

<>

The so-called 'blank node' in the l= inked data world, but then you're more reliant on a query language, suc= h as SPARQL.

I'm sure I havent covered every possibility.

OR you can key = off the Object

<anything>=A0 email <mailto:user@host>

then return all key values assoicated= with <anything> which would be in the @subject position in the case = of XRD/JRD or the @id position in the case of something like JSON LD

It's quite confusing but essentially you are asking two very differ= ent things:

1) Give me all information where the subject is acct:use= r@host

Which also means having to create a mapping, and educating ev= ery system what the subject of their email (or xmpp/sip/tel/twitter account= ) should be.=A0 A potentially big task.=A0 Im not saying it's wrong, bu= t IMHO this is potentially big enough to fill a whole other standards docum= ent in itself.

or

2) Give me all information for the user with email mailto:user@host

Non disruptive

I'= m sorry If i have not explained this very well, but the difference between = rev and rel confuses a lot of confusion in HTML, and that's essentially= the subtlety here (forward vs reverse lookup)
=A0
* Security agnostic - leave it to HTTP, TLS, OAuth, etc.

+1
=A0
* HTTP compliant - doesn't invent it's own rediretion menthods or c= ustom headers, etc.

+1
=A0

EH

> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of Mike Jones
> Sent: Thursday, April 19, 2012 9:49 AM
> To: Murray S. Kucherawy; oauth@ietf.= org WG; Apps Discuss
> Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web
> Discovery (SWD)
>
> There are two criteria t= hat I would consider to be essential requirements for
> any resulting general-purpose discovery specification:
>
> 1. =A0Being able to always discover per-user information with a single= GET
> (minimizing user interface latency for mobile devices, etc.)
>
> 2. =A0JSON should be required and it should be the only format require= d
> (simplicity and ease of deployment/adoption)
>
> SWD already meets those requirements. =A0If the resulting spec meets t= hose
> requirements, it doesn't matter a lot whether we call it WebFinger= or Simple
> Web Discovery, but I believe that the requirements discussion is proba= bly
> the most productive one to be having at this point - not the starting = point
> document.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike >
> -----Original Message-----
> From: apps-discuss-bo= unces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of= Murray S. Kucherawy
> Sent: Thursday, April 19, 2012 9:32 AM
> To: oauth@ietf.org WG; Apps Disc= uss
> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> Discovery (SWD)
>
> By all means people should correct me if they think I'm wrong abou= t this, but
> so far from monitoring the discussion there seems to be general suppor= t for
> focusing on WebFinger and developing it to meet the needs of those who=
> have deployed SWD, versus the opposite.
>
> Does anyone want to argue the opposite?
>
> -MSK, appsawg co-chair
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_____________________________= __________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d04389363d16d1604be0ea0a8-- From melvincarvalho@gmail.com Thu Apr 19 14:13:20 2012 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 EEC3721F84D5; Thu, 19 Apr 2012 14:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJPwgeUth906; Thu, 19 Apr 2012 14:13:19 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 653C621F84C4; Thu, 19 Apr 2012 14:13:19 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2432711vcb.31 for ; Thu, 19 Apr 2012 14:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xSw4icn76uXzdSvGS28TtX/oUs9ohqRG0lMdEFQsqM0=; b=G85dqAmbRtEg6JlSQC6tJzYGLS0X++XniEQigbjJlOIr679nNwRMenaTXz66wcnmRD diH4ca218Aqvq5+e+QVIeNRRyiC9l6QLMNYwzQOxYYwWvpJqCUXDWXcT7ekTS4hOGAsS 1YQOvlI6PSENR6TKDmKNcsQtfsSS72heAG0Lo2yjDRqK4mXANFj0lkhnsOB8NFUN0mWv jZFkUm3wG45twBEUGd84/eBsEM9EM/b3xWL2xso/1Ju02mi3uGZmTiVkvkiANDXv8omx DCwjpXTz9z0V7efETCQI8uWzCyLXszFRN8vuX151zZSFmBVsftcWeeH6tirrPgI39R3/ SaSw== MIME-Version: 1.0 Received: by 10.52.95.147 with SMTP id dk19mr1561835vdb.106.1334869998839; Thu, 19 Apr 2012 14:13:18 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Thu, 19 Apr 2012 14:13:18 -0700 (PDT) In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FF1C6A@P3PWEX2MB008.ex2.secureserver.net> Date: Thu, 19 Apr 2012 23:13:18 +0200 Message-ID: From: Melvin Carvalho To: Eran Hammer Content-Type: multipart/alternative; boundary=20cf3071d0b61a281104be0ea4dd Cc: "oauth@ietf.org WG" , Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Thu, 19 Apr 2012 21:13:21 -0000 --20cf3071d0b61a281104be0ea4dd Content-Type: text/plain; charset=ISO-8859-1 On 19 April 2012 23:12, Melvin Carvalho wrote: > > > On 19 April 2012 20:26, Eran Hammer wrote: > >> #1 as John Panzer identified, allowing the server to control its >> deployment and supporting HTTP redirects is critical. >> > > +1 > > >> #2 JSON is better, which one is required is less of on issue but more of >> a best practices item. >> > > Happy with this comment, and a +1 for JSON only > > >> >> I'll add: >> >> * Highly cachable >> > > +1 tho I think most CSN dont cache a 303 redirect > Apologies CSN should read CDN > > >> * Optimize for large providers, reducing the need to make repeated >> requests when the information is mostly following a template on the server >> side >> > > +1 > > >> * Ability to provide discovery on resources, not users or any other >> subset (emails, etc.) >> > > There's a subtlety here and that's the difference in HTML between "rel" > and "rev". > > A forward or reverse lookup. Forward is a natural way to look things up, > eg you give a URL and you get a document. But something like google search > is actually a reverse index, you give it words and you get back URLs for > documents. Initially hard to get your head round, but in practice can be > incredibly practical and useful. > > Given a triple such as (subject verb object) > > email > > Is your lookup based on the subject (WF) or the object (SWF)? > > If subject then you need something there. However, it need not be an > acct: URI > > It could be a URN eg > > urn:acct:user@host (no new uri scheme needed) > > it could be a relative URI such as > > <#> (which facebook do) > > This indicates a pointer to the top of the document > > It can even be blank > > <> > > The so-called 'blank node' in the linked data world, but then you're more > reliant on a query language, such as SPARQL. > > I'm sure I havent covered every possibility. > > OR you can key off the Object > > email > > then return all key values assoicated with which would be in > the @subject position in the case of XRD/JRD or the @id position in the > case of something like JSON LD > > It's quite confusing but essentially you are asking two very different > things: > > 1) Give me all information where the subject is acct:user@host > > Which also means having to create a mapping, and educating every system > what the subject of their email (or xmpp/sip/tel/twitter account) should > be. A potentially big task. Im not saying it's wrong, but IMHO this is > potentially big enough to fill a whole other standards document in itself. > > or > > 2) Give me all information for the user with email mailto:user@host > > Non disruptive > > I'm sorry If i have not explained this very well, but the difference > between rev and rel confuses a lot of confusion in HTML, and that's > essentially the subtlety here (forward vs reverse lookup) > > >> * Security agnostic - leave it to HTTP, TLS, OAuth, etc. >> > > +1 > > >> * HTTP compliant - doesn't invent it's own rediretion menthods or custom >> headers, etc. >> > > +1 > > >> >> EH >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> > Of Mike Jones >> > Sent: Thursday, April 19, 2012 9:49 AM >> > To: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss >> > Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web >> > Discovery (SWD) >> > >> > There are two criteria that I would consider to be essential >> requirements for >> > any resulting general-purpose discovery specification: >> > >> > 1. Being able to always discover per-user information with a single GET >> > (minimizing user interface latency for mobile devices, etc.) >> > >> > 2. JSON should be required and it should be the only format required >> > (simplicity and ease of deployment/adoption) >> > >> > SWD already meets those requirements. If the resulting spec meets those >> > requirements, it doesn't matter a lot whether we call it WebFinger or >> Simple >> > Web Discovery, but I believe that the requirements discussion is >> probably >> > the most productive one to be having at this point - not the starting >> point >> > document. >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> > bounces@ietf.org] On Behalf Of Murray S. Kucherawy >> > Sent: Thursday, April 19, 2012 9:32 AM >> > To: oauth@ietf.org WG; Apps Discuss >> > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web >> > Discovery (SWD) >> > >> > By all means people should correct me if they think I'm wrong about >> this, but >> > so far from monitoring the discussion there seems to be general support >> for >> > focusing on WebFinger and developing it to meet the needs of those who >> > have deployed SWD, versus the opposite. >> > >> > Does anyone want to argue the opposite? >> > >> > -MSK, appsawg co-chair >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > --20cf3071d0b61a281104be0ea4dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 19 April 2012 23:12, Melvin Carvalho = <melvincar= valho@gmail.com> wrote:


On 19 April 2012 20:26= , Eran Hammer <eran@hueniverse.com> wrote:
#1 as John Panzer identified, allowing the server to control its deployment= and supporting HTTP redirects is critical.

= +1
=A0
#2 JSON is better, which one is required is less of on issue but more of a = best practices item.

Happy with this comment= , and a +1 for JSON only
=A0

I'll add:

* Highly cachable

+1 tho I think most CSN do= nt cache a 303 redirect

Apologies CSN = should read CDN
=A0
=A0
* Optimize for large providers, reducing the need to make repeated requests= when the information is mostly following a template on the server side
=

+1
=A0
* Ability to provide discovery on resources, not users or any other subset = (emails, etc.)

There's a subtlety here a= nd that's the difference in HTML between "rel" and "rev&= quot;.=A0

A forward or reverse lookup.=A0 Forward is a natural way to look things= up, eg you give a URL and you get a document.=A0 But something like google= search is actually a reverse index, you give it words and you get back URL= s for documents.=A0 Initially hard to get your head round, but in practice = can be incredibly practical and useful.

Given a triple such as (subject verb object)

<acct:user@host&= gt;=A0 email=A0 <mailto:u= ser@host>

Is your lookup based on the subject (WF) or the obj= ect (SWF)?=A0

If subject then you need something there.=A0 However, it need not be an acc= t: URI

It could be a URN eg

urn:acct:user@host=A0 (no new uri= scheme needed)

it could be a relative URI such as

<#>= =A0 (which facebook do)

This indicates a pointer to the top of the document

It can even = be blank

<>

The so-called 'blank node' in the l= inked data world, but then you're more reliant on a query language, suc= h as SPARQL.

I'm sure I havent covered every possibility.

OR you can key = off the Object

<anything>=A0 email <mailto:user@host>

then return all key= values assoicated with <anything> which would be in the @subject pos= ition in the case of XRD/JRD or the @id position in the case of something l= ike JSON LD

It's quite confusing but essentially you are asking two very differ= ent things:

1) Give me all information where the subject is acct:use= r@host

Which also means having to create a mapping, and educating ev= ery system what the subject of their email (or xmpp/sip/tel/twitter account= ) should be.=A0 A potentially big task.=A0 Im not saying it's wrong, bu= t IMHO this is potentially big enough to fill a whole other standards docum= ent in itself.

or

2) Give me all information for the user with email mailto:user@host

Non disrup= tive

I'm sorry If i have not explained this very well, but the d= ifference between rev and rel confuses a lot of confusion in HTML, and that= 's essentially the subtlety here (forward vs reverse lookup)
=A0
* HTTP compliant - doesn't invent it's own rediretion menthods or c= ustom headers, etc.

+1
=A0

EH

> -----Original Message-----
> From: oaut= h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Mike Jones
> Sent: Thursday, April 19, 2012 9:49 AM
> To: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss
> Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web
> Discovery (SWD)
>
> There are two criteria that I would consider to be ess= ential requirements for
> any resulting general-purpose discovery specification:
>
> 1. =A0Being able to always discover per-user information with a single= GET
> (minimizing user interface latency for mobile devices, etc.)
>
> 2. =A0JSON should be required and it should be the only format require= d
> (simplicity and ease of deployment/adoption)
>
> SWD already meets those requirements. =A0If the resulting spec meets t= hose
> requirements, it doesn't matter a lot whether we call it WebFinger= or Simple
> Web Discovery, but I believe that the requirements discussion is proba= bly
> the most productive one to be having at this point - not the starting = point
> document.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike >
> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org= ] On Behalf Of Murray S. Kucherawy
> Sent: Thursday, April 19, 2012 9:32 AM
> To: oauth@ietf.org= WG; Apps Discuss
> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> Discovery (SWD)
>
> By all means people should correct me if they think I'm wrong abou= t this, but
> so far from monitoring the discussion there seems to be general suppor= t for
> focusing on WebFinger and developing it to meet the needs of those who=
> have deployed SWD, versus the opposite.
>
> Does anyone want to argue the opposite?
>
> -MSK, appsawg co-chair
>
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
> _______________________________________________
_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

On 15 April 2012 08:21, Eran Hammer <eran@hueniverse.co= m> wrote:

Tone aside, this is not t= he first time you distorted process and technical facts to suit your goals.= Just look up some of our exchanges from a year ago and the transcript of the Prague meeting for highlights.


As stephen suggests, could we possibly continue this= fascinating discussion on apps discuss?=A0

I know people are passi= onate about this issue, and that's a positive thing.=A0

But I think it probably would be most productive, if we could all try t= o keep personal attacks to a minimum.
=A0

=A0<= /p>

EH

=A0<= /p>

=A0<= /p>

=A0<= /p>

From: oauth-bounces@ietf.org= [mailto:oa= uth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, April 13, 2012 9:18 AM
To: Blaine Cook
Cc: oauth@ietf.o= rg WG


Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)=

=A0

Hi Blaine.=A0 I must admi= t, I=92m pretty surprised by the tone of your reply.=A0 I=92ll say up front= that I have absolutely no problem with anyone disagreeing with me on a technical or tactical basis.=A0 If you think I=92m wrong, have at = it.

=A0<= /p>

But I am pretty shocked t= hat you would decide to impugn my motives.=A0 We=92ve only met twice and bo= th times I thought we had really useful and productive discussions about how to move digital identity on the Web forward =96 something I beli= eve that we=92re both passionate about.=A0 You don=92t really know me, thou= gh, which is apparent from your remarks below.=A0 I believe that those who = have worked with me for years would vouch that I am a forthright and evenhanded standards participant who listens to= all points of view, tries to build a consensus that works, and produce qua= lity results.

=A0<= /p>

I thought about your note= overnight and whether I should reply at all.=A0 I=92m fine with give and t= ake, but I believe that I need to say that if you read what you wrote below, I think you=92ll agree that the tone you used was counter= -productive and an apology is in order.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

P.S.=A0 I=92ll address yo= ur technical points below in a separate note at some point =96 some I agree= with and some I don=92t.=A0 But I felt that I needed to address my motives being questioned separately and first.=A0 I hope we can both come = out of this with a better understanding of one another and work together to= wards the important goals that we both share.

=A0<= /p>

From: Blaine C= ook [mailto:rome= da@gmail.com]
Sent: Thursday, April 12, 2012 3:41 PM
To: Mike Jones
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)=

=A0

On 12 April 2012 17:51, Mike Jones <Michael.Jones@microsoft= .com> wrote:

Thanks for asking these questions Hannes. =A0I'l= l first provide a brief feature comparison of Simple Web Discovery and WebF= inger and then answer your questions.

FEATURE COMPARISON

RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: =A0SWD returns the resource= location(s) for a specific resource for a specific principal. =A0WebFinger= returns all resources for the principal. =A0The example at http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2= "Retrieving a Person's Contact Information" is telling. =A0T= he WebFinger usage model seems to be "I'll get everything about yo= u and then fish through it to decide what to do with it." =A0The protocol assumption that all WebFinger information must be public i= s also built into the protocol where the CORS response header "Access-= Control-Allow-Origin: *" is mandated, per http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7. = =A0The privacy characteristics of these approaches are very different. =A0(= It's these very same privacy characteristics that led sysadmins to near= ly ubiquitously disabling the fingerd service!) =A0Particularly for the OAuth use cases, narrow, scoped, and potentially p= ermissioned responses seem preferable.

=A0

This is absolutely false.

=A0

SWD provides no privacy whatsoever. SWD makes it som= ewhat harder to crawl large numbers of profiles, but it does not incorporat= e any real security, and any attempt to suggest that it does is misleading = and deceptive.

=A0

Webfinger, like any good HTTP service, is designed t= o allow access control using appropriate means. That access control should = not be *bound* to the protocol, in the same way that HTTP does not have any= REQUIRED access control mechanisms, since doing so would severely restrict future usage of a core protocol.=

=A0

FUD has no place in a discussion of the technical an= d social merits of a protocol.

=A0

For what it's worth, my intent with webfinger *f= rom day one, nearly four years ago*, has been to provide permissioned profi= le data *using EXISTING* (or new, where appropriate or necessary, based on = *running code and deployment EXPERIENCE*) access control mechanisms for profile data.

=A0

The idea that there is ONE view of the data is paten= tly false. For example, depending on who is requesting my profile data, I m= ight return different contact telephone numbers, and this behaviour is comp= letely feasible using webfinger.

=A0

DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURI= TY: =A0WebFinger is built on a "document model", where a single d= ocument is returned that contains multiple resources for a principal. =A0SW= D is built on an "API model", where the location(s) of a particular resource for a principal are returned. =A0The problem with= the document model is that different parties or services may be authoritat= ive for different resources for a given principal, and yet all need the rig= hts to edit the resulting document. =A0This hurts deployability, because document edits then need to be coordi= nated among parties that may have different rights and responsibilities, an= d may have negative security implications as well. =A0(Just because I can c= hange your avatar doesn't mean that I should be able to change your mail server.)

=A0

WS-* was built on an API model, and that worked out = very well.

=A0

APIs and documents on the web are the same thing; ho= w you represent them behind the scenes is up to you, and that's been a = core principle of the web since shortly after its inception. Suggesting oth= erwise profoundly misunderstands how implementation of web services happens.

=A0

SWD says nothing of how to update profile data, so t= he security concerns here are a total red herring.

=A0

REDIRECT FUNCTIONALITY AND DEPLOYABILTY: =A0SWD incl= udes the ability to redirect some or all SWD requests to another location (= possibly depending upon the specific resource and principal parameters). = =A0Deployers hosting numerous sites for others told the SWD authors that this functionality is critical for deploy= ability, as it means that the SWD server for a domain can live in a locatio= n outside the domain. =A0WebFinger is lacking this functionality. =A0Given = that OAuth is likely to be used in hosted environments, this functionality seems pretty important.

=A0

Umm, I'm not even sure what to say to this. host= -meta is a static file that points to a profile server (generally expected = to be a dynamic "API" server) that can be hosted on any domain.

=A0

The fact that you're suggesting that this core p= iece of webfinger functionality is *missing* seriously undermines my belief= that you're acting in good faith, Mike.

=A0

NUMBER OF ROUND TRIPS: =A0WebFinger discoveries for = user information normally require both a host-meta query to retrieve the te= mplate and then a second query to retrieve the user's information. =A0T= his functionality is achieved in a single SWD query.

=A0

... at the cost of greater client complexity. A webf= inger lookup may be implemented with the following trivial shell script:=

=A0

= curl -s http://example.com/.well-known/host-meta|awk "/lrdd/,/template/&qu= ot;|tr -d '\n'|sed -e "s/^.*template=3D'\([^']*\)'= .*$/\1/"|sed -e "s/{uri}/user@example.com/"|xargs curl -s

=A0

so long as your HTTP client properly follows redirec= ts, this approach will always produce a valid webfinger profile, and if pro= per caching is implemented, will only make requests to /.well-known/host-me= ta when the document is expired.

=A0

SWD, on the other hand, implements a non-HTTP redire= ct mechanism, meaning that optimal caching rules can't be obeyed by sta= ndard HTTP clients. Moreover, SWD *requires* conditionals by presenting one= code path for the non-redirect case and one code path for the immediate response case.

=A0

The complexity for client implementations should be = foremost in this work, and the decisions made by SWD don't indicate to = me that these factors have been considered.

=A0

Indeed, I wonder why=A0is SWD designed to pre-optimi= ze for presumed scaling challenges that are faced by only the very largest = providers (namely, the fact that two lookups are required for webfinger ins= tead of one in the ideal case), when:

=A0

1. Those scaling challenges are simply not real thre= ats. host-meta can be cached using existing HTTP mechanisms

2. The fact that SWD only returns one service defini= tion per request means that more than one request will often be required to= obtain the necessary information about a user.

3. The chances that Google or Microsoft will host dy= namic response SWD services on the gmail.com or hotmail.com domains is next to ni= l, and will therefore need to issue redirects anyways.

=A0

For smaller providers (e.g., personal domains hosted= in static or rigid environments), hosting a SWD server at /.well-known/sim= ple-web-discovery may be challenging indeed. Thus, all clients will need to= support the redirect behaviour natively, and for those who write specs but not code, it is *more* complex to have c= onditional behaviour like that than to have a defined flow that is always f= ollowed.

=A0

Further, it's more complex for small service pro= viders to host static content that is invariant and properly cached (e.g., = by transparent proxy caches like varnish and squid) when CGI parameters are= appended, as with SWD.

=A0

XML AND JSON VERSUS JSON: =A0WebFinger specifies bot= h XML and JSON support, whereas SWD specifies only JSON. =A0The SWD positio= n is that it's simpler to specify only one way of doing the same thing,= with JSON being chosen because it's simpler for developers to use than XML - the same decision as made for the OAuth s= pecs.

=A0

Webfinger only used XRD in the first place to satisf= y the OpenID community. This is infuriating format-fetishism, and misses th= e point entirely. JSON is preferred, and I, for one, would happily modify h= ost-meta and webfinger to require JSON is people feel this strongly about it.

=A0

DEFINING SPECIFIC RESOURCES: =A0Besides specifying a= discovery protocol, WebFinger also defines specific resources and kinds of= resources to be used with that protocol: =A0the "acct" URI schem= e, the "acct" Link Relation. =A0These should be considered on their own merits, but logically should be decoupled from the discovery = protocol into a different document or documents. =A0It's not clear thes= e features would be needed in OAuth contexts.

=A0

I have long argued against the acct URI, but the con= sensus-based approach of the IETF has over-ridden me on that one. If you fe= el similarly, you are free to voice that opinion.

=A0

It shocks me that you're saying that the OAuth W= G shouldn't consider host-meta/webfinger because it defines something t= hat isn't of interest to the OAuth WG. The whole point of my argument a= t the WG meeting in Paris was that Webfinger and SWD-like protocols are of such consequence to the web at large that the in= terests of the OAuth WG should not be used to define the parameters for the= ir behaviour.

=A0

I'm more convinced that you're using your po= wer within this WG to have SWD rubber-stamped so that you can ship OpenID C= onnect as you've defined it.

=A0

QUESTIONS


1) Aren't these two mechanisms solving pretty much the same problem?=

=A0 =A0 =A0 =A0 =A0 =A0 =A0 They are solving an over= lapping set of problems, but with very different privacy characteristics, d= ifferent deployability characteristics, different security characteristics,= and somewhat different mechanisms.

=A0

Again, I totally disagree with your assessment here,= Mike.

=A0

2) Do we need to have= two standards for the same functionality?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 No - Simple Web Discover= y is sufficient for the OAuth use cases (and likely for others as well).=

=A0

I agree with this =96 since SWD is an explicit (thou= gh unstated) fork of Webfinger, there is no need to have two standards.<= /u>

=A0

3) Do you guys have a= position or comments regarding either one of them?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 The functionality in Sim= ple Web Discovery is minimal and sufficient for the OAuth use cases, wherea= s some of the functionality and assumptions made in WebFinger are harmful, = both from a privacy and from a deployability perspective. =A0SWD should proceed to standardization; WebFinger should not.<= /u>

=A0

I believe Mike has made misleading statements regard= ing the privacy and deployability perspective, either intentionally, or bec= ause he fundamentally does not understand the security or deployment scenar= ios that motivate the decisions.

=A0

In summary:

=A0

1. I believe that SWD and Webfinger are essentially = the same protocol, with different authors names at the top.

2. I don't care which one "wins", thou= gh I think that SWD's use of HTTP is questionable, and that the claims = of privacy and deployability advantages offered by SWD are overblown and po= tentially misleading.

3. My concerns about SWD apply equally to any concer= ns anyone would leverage against Webfinger.

4. Which is to say, I think we should have one proto= col that is defined by an open discussion.

5. We've had an open discussion on the webfinger= list and apps-discuss and in the context of host-meta that the SWD folks h= ave chosen not to engage with for the past three years.

6. The OAuth list is *not* the place for this discus= sion to happen, just so that Mike Jones can quickly push a spec through the= formal process using a list that has well-known problems of too-high mail = volume and whose topic is unrelated to the goals of Webfinger/SWD.

=A0

This is important enough to get right, and getting i= t wrong will almost certainly lead to years of incompatibility and frustrat= ion, as Stephen mentioned. I encourage everyone involved to take this serio= usly, let go of personal attachment and presumptions of dependencies, and consider this work in an appropriate= context (with an inclusive, not exclusive community).

=A0

b.


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--20cf3071d0b61a281104be0ea4dd-- From Adam.Lewis@motorolasolutions.com Thu Apr 19 14:38:13 2012 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 8F02911E80D2 for ; Thu, 19 Apr 2012 14:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA89LWPo0Vms for ; Thu, 19 Apr 2012 14:38:11 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBD211E8096 for ; Thu, 19 Apr 2012 14:38:10 -0700 (PDT) Received: from mail103-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 21:38:10 +0000 Received: from mail103-ch1 (localhost [127.0.0.1]) by mail103-ch1-R.bigfish.com (Postfix) with ESMTP id 029924C025F for ; Thu, 19 Apr 2012 21:38:10 +0000 (UTC) X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI9371Ic85fh98dK14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25h) X-Forefront-Antispam-Report: CIP:129.188.136.17; KIP:(null); UIP:(null); IPV:NLI; H:il06msg01.mot-solutions.com; RD:none; EFVD:NLI Received-SPF: pass (mail103-ch1: domain of motorolasolutions.com designates 129.188.136.17 as permitted sender) client-ip=129.188.136.17; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg01.mot-solutions.com ; olutions.com ; Received: from mail103-ch1 (localhost.localdomain [127.0.0.1]) by mail103-ch1 (MessageSwitch) id 1334871487718060_30710; Thu, 19 Apr 2012 21:38:07 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail103-ch1.bigfish.com (Postfix) with ESMTP id ACFDF14005A for ; Thu, 19 Apr 2012 21:38:07 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 21:38:07 +0000 Received: from il06msg01.mot-solutions.com (il06vts03.mot.com [129.188.137.143]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3JMKqt5010995 for ; Thu, 19 Apr 2012 17:20:52 -0500 (CDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3JMKpuB010991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Apr 2012 17:20:52 -0500 (CDT) Received: from mail96-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 21:38:06 +0000 Received: from mail96-va3 (localhost [127.0.0.1]) by mail96-va3-R.bigfish.com (Postfix) with ESMTP id 06B383403FB for ; Thu, 19 Apr 2012 21:38:06 +0000 (UTC) Received: from mail96-va3 (localhost.localdomain [127.0.0.1]) by mail96-va3 (MessageSwitch) id 1334871483455180_21352; Thu, 19 Apr 2012 21:38:03 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.240]) by mail96-va3.bigfish.com (Postfix) with ESMTP id 68B992C0264; Thu, 19 Apr 2012 21:38:03 +0000 (UTC) Received: from CH1PRD0410HT003.namprd04.prod.outlook.com (157.56.244.181) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 21:37:58 +0000 Received: from CH1PRD0410MB369.namprd04.prod.outlook.com ([169.254.6.182]) by CH1PRD0410HT003.namprd04.prod.outlook.com ([10.255.147.38]) with mapi id 14.16.0143.004; Thu, 19 Apr 2012 21:37:57 +0000 From: Lewis Adam-CAL022 To: Justin Richer Thread-Topic: [OAUTH-WG] Using OAuth to get a JWT/SAML token Thread-Index: AQHNGZQHGnbSav9o6k2Y2ikZeKN005aitRMw Date: Thu, 19 Apr 2012 21:37:56 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9090519@CH1PRD0410MB369.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A906E74E@CH1PRD0410MB369.namprd04.prod.outlook.com> <4F885680.5090801@mitre.org> In-Reply-To: <4F885680.5090801@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.9.149] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9090519CH1PRD0410MB369na_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0410HT003.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False;00160000;True;; X-OrganizationHeadersPreserved: CH1PRD0410HT003.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MITRE.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Thu, 19 Apr 2012 21:38:13 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9090519CH1PRD0410MB369na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Justin, There is one thing I have not understood about the whole external browser v= s. embedded browser guidance ... and that is, why is *any* browser needed? = Java for example has an HTTP library, and OAuth is RESTful. So why is it = necessary to require the web browser at all, whether external or embedded? = Why can't my native client make RESTful API calls to the AS and RS nativel= y? Tx! adam From: Justin Richer [mailto:jricher@mitre.org] Sent: Friday, April 13, 2012 11:38 AM To: Lewis Adam-CAL022 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token If the mobile device has a web browser (such as a smart phone), then this i= s pretty easy, and you've got a couple of options. One of the best options when the token is on behalf of an end user is, in m= y opinion, to use the authorization code flow like this: First, register wh= at's called a "public client" with your server -- so you'll get an ID but n= ot a client secret. With that client ID, register a custom-scheme callback = URI, like "myapp://oauthcallback", and register your app on the device as t= he handler for "myapp". In your application, to start things off, you fire off a web browser to the= authorization server's authorization endpoint. The user logs in to the aut= horization server through the web browser, approves this copy of your app, = and gets redirected to "myapp://oauthcallback?code=3Dbasdf132". Your app gr= abs the "myapp://" url and plucks the authorization code off the end of it.= Your app then takes that code and sends it in the background to the token = endpoint to exchange for a token. Some key points: 1) You need to have access to a web browser on the platform, and it's consi= dered best practice to push the user to the external browser application on= the platform instead of embedding one. There are a couple paragraphs in th= e spec's security considerations section that talk about this. 2) Your app is "public" because you can't publish it with a secret at confi= guration time. It can, however, keep the tokens secret at runtime. 3) You need to be very careful with how you store the tokens on the device = -- they need to be in a trusted space where other apps on the device can't = sniff them out. 4) Another app can try to register "myapp://" and intercept your code on th= e way through, so make sure your codes are all one time use and short lived= . None of this is just theoretically possible, people are doing it today. Wha= t libraries and stuff you'd be after depends wholly on your platform (both = server and client side). -- Justin On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote: Hi all, I've been talking to some of you off line about this already, but I need so= me help in terms of implementation. I would like to use OAuth as a means t= o get either a JWT or SAML token to a client running on a handheld device. = This is something that I'm looking to prototype (as part of a larger proje= ct) beginning this week. So, it is important to me to understand the divid= e between what is theoretically possible and what is actually possible. Anybody aware of any implementations out there, either vendor or open sourc= e, that I can use for this? Tx! adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A9090519CH1PRD0410MB369na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Just= in,

&n= bsp;

There i= s one thing I have not understood about the whole external browser vs. embe= dded browser guidance … and that is, why is *any* browser need= ed?  Java for example has an HTTP library, and OAuth is RESTful.  So why is it necessary to require the web brow= ser at all, whether external or embedded?  Why can’t my native c= lient make RESTful API calls to the AS and RS natively?

&n= bsp;

Tx!

adam

&n= bsp;

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, April 13, 2012 11:38 AM
To: Lewis Adam-CAL022
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

 

If the mobile device has a web browser (such as a sm= art phone), then this is pretty easy, and you've got a couple of options.
One of the best options when the token is on behalf of an end user is, in m= y opinion, to use the authorization code flow like this: First, register wh= at's called a "public client" with your server -- so you'll get a= n ID but not a client secret. With that client ID, register a custom-scheme callback URI, like "myapp://oauthcallbac= k", and register your app on the device as the handler for "myapp= ".

In your application, to start things off, you fire off a web browser to the= authorization server's authorization endpoint. The user logs in to the aut= horization server through the web browser, approves this copy of your app, = and gets redirected to "myapp://oauthcallback?code=3Dbasdf132". Your app grabs the "myapp://" url and plucks the authorization c= ode off the end of it. Your app then takes that code and sends it in the ba= ckground to the token endpoint to exchange for a token.

Some key points:

1) You need to have access to a web browser on the platform, and it's consi= dered best practice to push the user to the external browser application on= the platform instead of embedding one. There are a couple paragraphs in th= e spec's security considerations section that talk about this.
2) Your app is "public" because you can't publish it with a secre= t at configuration time. It can, however, keep the tokens secret at runtime= .
3) You need to be very careful with how you store the tokens on the device = -- they need to be in a trusted space where other apps on the device can't = sniff them out.
4) Another app can try to register "myapp://" and intercept your = code on the way through, so make sure your codes are all one time use and s= hort lived.

None of this is just theoretically possible, people are doing it today. Wha= t libraries and stuff you'd be after depends wholly on your platform (both = server and client side).

 -- Justin

On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote:

Hi all,=

 <= /o:p>

I’ve been tal= king to some of you off line about this already, but I need some help in te= rms of implementation.  I would like to use OAuth as a means to get ei= ther a JWT or SAML token to a client running on a handheld device.  This is something that I’m looking to proto= type (as part of a larger project) beginning this week.  So, it is imp= ortant to me to understand the divide between what is theoretically possibl= e and what is actually possible.

 <= /o:p>

Anybody aware of an= y implementations out there, either vendor or open source, that I can use f= or this?

 <= /o:p>

Tx!
adam




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ie=
tf.org/mailman/listinfo/oauth

 

--_000_59E470B10C4630419ED717AC79FCF9A9090519CH1PRD0410MB369na_-- From paul.madsen@gmail.com Thu Apr 19 15:03:09 2012 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 7194C11E80C7 for ; Thu, 19 Apr 2012 15:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj94DZrs19iJ for ; Thu, 19 Apr 2012 15:03:08 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5A97611E80BB for ; Thu, 19 Apr 2012 15:03:08 -0700 (PDT) Received: by qaea16 with SMTP id a16so33650qae.10 for ; Thu, 19 Apr 2012 15:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:importance:from:to:cc:mime-version :content-type; bh=vQBWz83v36gv1A7A7f4YJcDnP6DA6SjTKHoOyph0Leg=; b=caTUHiW7fIcbXG/Q1yD/EJ/6rdsyv+RABZssRc5F4oAAOb15bWmHvoxlwC0qpqs4tp tv5C3Y3N0GaPJP1wnlxQfNnP3R1BZkl6SXjm6UPCphn2z0G5I9Yvrz/GYexAqSFV4ir/ FTJBa2hAhYjKy/s/ParAydupl+A4EO2VvYio5zkENplnnS177DzfeQUphy9jlLiUn0VP eE7iEpEsOd2lEYCdmaWvOHlgNmI0TklcVmvAlkx0UPHh84mWuJx+klREIlLWqxpPIYUa xD423mHsrgioWh7d/KyhIFbdSNXNP37205iw7KzrHiriZHsIX5Piw8M/1Jgt0SC2MulE hXLQ== Received: by 10.229.135.212 with SMTP id o20mr1529335qct.146.1334872987881; Thu, 19 Apr 2012 15:03:07 -0700 (PDT) Received: from [10.144.20.21] (mobile-198-228-205-210.mycingular.net. [198.228.205.210]) by mx.google.com with ESMTPS id gy7sm6623799qab.22.2012.04.19.15.03.05 (version=SSLv3 cipher=OTHER); Thu, 19 Apr 2012 15:03:07 -0700 (PDT) Date: Thu, 19 Apr 2012 17:03:02 -0500 Message-ID: <5jrlua1y80mdxtvpmygf5tp1.1334872982862@email.android.com> Importance: normal From: Paul Madsen To: adam.lewis@motorolasolutions.com, jricher@mitre.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_73935595691294" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Thu, 19 Apr 2012 22:03:09 -0000 ----_com.android.email_73935595691294 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VXNpbmcgdGhlIGJyb3dzZXIgYXMgcGFydCBvZiB0aGUgQVMgaW50ZXJhY3Rpb24gYWxsb3dzIHlv dSB0byBtb3JlIGVhc2lseSBjb2xsZWN0IHRoZSB1c2VycyBjb25zZW50LsKgCgpPbmNlIHlvdSBn ZXQgdGhlIHRva2VucyBiYXNlZCBvbiB0aGF0IGNvbnNlbnQsIGV2ZXJ5dGhpbmcgaXMgJ1JFU1Rm dWwnCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tClN1YmplY3Q6IFJlOiBbT0FV VEgtV0ddIFVzaW5nIE9BdXRoIHRvIGdldCBhIEpXVC9TQU1MIHRva2VuCkZyb206IExld2lzIEFk YW0tQ0FMMDIyIDxBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbT4KVG86IEp1c3RpbiBS aWNoZXIgPGpyaWNoZXJAbWl0cmUub3JnPgpDQzogUmU6IFtPQVVUSC1XR10gVXNpbmcgT0F1dGgg dG8gZ2V0IGEgSldUL1NBTUwgdG9rZW4KCkhpIEp1c3RpbiwKCsKgCgpUaGVyZSBpcyBvbmUgdGhp bmcgSSBoYXZlIG5vdCB1bmRlcnN0b29kIGFib3V0IHRoZSB3aG9sZSBleHRlcm5hbCBicm93c2Vy IHZzLiBlbWJlZGRlZCBicm93c2VyIGd1aWRhbmNlIOKApiBhbmQgdGhhdCBpcywgd2h5IGlzICph bnkqIGJyb3dzZXIgbmVlZGVkP8KgIEphdmEgZm9yIGV4YW1wbGUgaGFzIGFuIEhUVFAgbGlicmFy eSwgYW5kIE9BdXRoIGlzIFJFU1RmdWwuwqAgU28gd2h5IGlzIGl0IG5lY2Vzc2FyeSB0byByZXF1 aXJlIHRoZSB3ZWIgYnJvd3NlciBhdCBhbGwsIHdoZXRoZXIgZXh0ZXJuYWwgb3IgZW1iZWRkZWQ/ wqAgV2h5IGNhbuKAmXQgbXkgbmF0aXZlIGNsaWVudCBtYWtlIFJFU1RmdWwgQVBJIGNhbGxzIHRv IHRoZSBBUyBhbmQgUlMgbmF0aXZlbHk/CgrCoAoKVHghCgphZGFtCgrCoAoKRnJvbTogSnVzdGlu IFJpY2hlciBbbWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnXSAKU2VudDogRnJpZGF5LCBBcHJpbCAx MywgMjAxMiAxMTozOCBBTQpUbzogTGV3aXMgQWRhbS1DQUwwMjIKQ2M6IG9hdXRoQGlldGYub3Jn ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFVzaW5nIE9BdXRoIHRvIGdldCBhIEpXVC9TQU1MIHRv a2VuCgrCoAoKSWYgdGhlIG1vYmlsZSBkZXZpY2UgaGFzIGEgd2ViIGJyb3dzZXIgKHN1Y2ggYXMg YSBzbWFydCBwaG9uZSksIHRoZW4gdGhpcyBpcyBwcmV0dHkgZWFzeSwgYW5kIHlvdSd2ZSBnb3Qg YSBjb3VwbGUgb2Ygb3B0aW9ucy4KCk9uZSBvZiB0aGUgYmVzdCBvcHRpb25zIHdoZW4gdGhlIHRv a2VuIGlzIG9uIGJlaGFsZiBvZiBhbiBlbmQgdXNlciBpcywgaW4gbXkgb3BpbmlvbiwgdG8gdXNl IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZmxvdyBsaWtlIHRoaXM6IEZpcnN0LCByZWdpc3RlciB3 aGF0J3MgY2FsbGVkIGEgInB1YmxpYyBjbGllbnQiIHdpdGggeW91ciBzZXJ2ZXIgLS0gc28geW91 J2xsIGdldCBhbiBJRCBidXQgbm90IGEgY2xpZW50IHNlY3JldC4gV2l0aCB0aGF0IGNsaWVudCBJ RCwgcmVnaXN0ZXIgYSBjdXN0b20tc2NoZW1lIGNhbGxiYWNrIFVSSSwgbGlrZSAibXlhcHA6Ly9v YXV0aGNhbGxiYWNrIiwgYW5kIHJlZ2lzdGVyIHlvdXIgYXBwIG9uIHRoZSBkZXZpY2UgYXMgdGhl IGhhbmRsZXIgZm9yICJteWFwcCIuIAoKSW4geW91ciBhcHBsaWNhdGlvbiwgdG8gc3RhcnQgdGhp bmdzIG9mZiwgeW91IGZpcmUgb2ZmIGEgd2ViIGJyb3dzZXIgdG8gdGhlIGF1dGhvcml6YXRpb24g c2VydmVyJ3MgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gVGhlIHVzZXIgbG9ncyBpbiB0byB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgdGhyb3VnaCB0aGUgd2ViIGJyb3dzZXIsIGFwcHJvdmVzIHRo aXMgY29weSBvZiB5b3VyIGFwcCwgYW5kIGdldHMgcmVkaXJlY3RlZCB0byAibXlhcHA6Ly9vYXV0 aGNhbGxiYWNrP2NvZGU9YmFzZGYxMzIiLiBZb3VyIGFwcCBncmFicyB0aGUgIm15YXBwOi8vIiB1 cmwgYW5kIHBsdWNrcyB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIG9mZiB0aGUgZW5kIG9mIGl0LiBZ b3VyIGFwcCB0aGVuIHRha2VzIHRoYXQgY29kZSBhbmQgc2VuZHMgaXQgaW4gdGhlIGJhY2tncm91 bmQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRvIGV4Y2hhbmdlIGZvciBhIHRva2VuLiAKClNvbWUg a2V5IHBvaW50czogCgoxKSBZb3UgbmVlZCB0byBoYXZlIGFjY2VzcyB0byBhIHdlYiBicm93c2Vy IG9uIHRoZSBwbGF0Zm9ybSwgYW5kIGl0J3MgY29uc2lkZXJlZCBiZXN0IHByYWN0aWNlIHRvIHB1 c2ggdGhlIHVzZXIgdG8gdGhlIGV4dGVybmFsIGJyb3dzZXIgYXBwbGljYXRpb24gb24gdGhlIHBs YXRmb3JtIGluc3RlYWQgb2YgZW1iZWRkaW5nIG9uZS4gVGhlcmUgYXJlIGEgY291cGxlIHBhcmFn cmFwaHMgaW4gdGhlIHNwZWMncyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRoYXQg dGFsayBhYm91dCB0aGlzLgoyKSBZb3VyIGFwcCBpcyAicHVibGljIiBiZWNhdXNlIHlvdSBjYW4n dCBwdWJsaXNoIGl0IHdpdGggYSBzZWNyZXQgYXQgY29uZmlndXJhdGlvbiB0aW1lLiBJdCBjYW4s IGhvd2V2ZXIsIGtlZXAgdGhlIHRva2VucyBzZWNyZXQgYXQgcnVudGltZS4KMykgWW91IG5lZWQg dG8gYmUgdmVyeSBjYXJlZnVsIHdpdGggaG93IHlvdSBzdG9yZSB0aGUgdG9rZW5zIG9uIHRoZSBk ZXZpY2UgLS0gdGhleSBuZWVkIHRvIGJlIGluIGEgdHJ1c3RlZCBzcGFjZSB3aGVyZSBvdGhlciBh cHBzIG9uIHRoZSBkZXZpY2UgY2FuJ3Qgc25pZmYgdGhlbSBvdXQuCjQpIEFub3RoZXIgYXBwIGNh biB0cnkgdG8gcmVnaXN0ZXIgIm15YXBwOi8vIiBhbmQgaW50ZXJjZXB0IHlvdXIgY29kZSBvbiB0 aGUgd2F5IHRocm91Z2gsIHNvIG1ha2Ugc3VyZSB5b3VyIGNvZGVzIGFyZSBhbGwgb25lIHRpbWUg dXNlIGFuZCBzaG9ydCBsaXZlZC4KCk5vbmUgb2YgdGhpcyBpcyBqdXN0IHRoZW9yZXRpY2FsbHkg cG9zc2libGUsIHBlb3BsZSBhcmUgZG9pbmcgaXQgdG9kYXkuIFdoYXQgbGlicmFyaWVzIGFuZCBz dHVmZiB5b3UnZCBiZSBhZnRlciBkZXBlbmRzIHdob2xseSBvbiB5b3VyIHBsYXRmb3JtIChib3Ro IHNlcnZlciBhbmQgY2xpZW50IHNpZGUpLiAKCsKgLS0gSnVzdGluCgpPbiAwNC8xMi8yMDEyIDAz OjAxIFBNLCBMZXdpcyBBZGFtLUNBTDAyMiB3cm90ZToKCkhpIGFsbCwKCsKgCgpJ4oCZdmUgYmVl biB0YWxraW5nIHRvIHNvbWUgb2YgeW91IG9mZiBsaW5lIGFib3V0IHRoaXMgYWxyZWFkeSwgYnV0 IEkgbmVlZCBzb21lIGhlbHAgaW4gdGVybXMgb2YgaW1wbGVtZW50YXRpb24uwqAgSSB3b3VsZCBs aWtlIHRvIHVzZSBPQXV0aCBhcyBhIG1lYW5zIHRvIGdldCBlaXRoZXIgYSBKV1Qgb3IgU0FNTCB0 b2tlbiB0byBhIGNsaWVudCBydW5uaW5nIG9uIGEgaGFuZGhlbGQgZGV2aWNlLsKgIFRoaXMgaXMg c29tZXRoaW5nIHRoYXQgSeKAmW0gbG9va2luZyB0byBwcm90b3R5cGUgKGFzIHBhcnQgb2YgYSBs YXJnZXIgcHJvamVjdCkgYmVnaW5uaW5nIHRoaXMgd2Vlay7CoCBTbywgaXQgaXMgaW1wb3J0YW50 IHRvIG1lIHRvIHVuZGVyc3RhbmQgdGhlIGRpdmlkZSBiZXR3ZWVuIHdoYXQgaXMgdGhlb3JldGlj YWxseSBwb3NzaWJsZSBhbmQgd2hhdCBpcyBhY3R1YWxseSBwb3NzaWJsZS4KCsKgCgpBbnlib2R5 IGF3YXJlIG9mIGFueSBpbXBsZW1lbnRhdGlvbnMgb3V0IHRoZXJlLCBlaXRoZXIgdmVuZG9yIG9y IG9wZW4gc291cmNlLCB0aGF0IEkgY2FuIHVzZSBmb3IgdGhpcz8KCsKgCgpUeCEKYWRhbQoKCgoK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk9BdXRoIG1h aWxpbmcgbGlzdApPQXV0aEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoCsKg ----_com.android.email_73935595691294 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5Vc2luZyB0aGUgYnJvd3NlciBhcyBw YXJ0IG9mIHRoZSBBUyBpbnRlcmFjdGlvbiBhbGxvd3MgeW91IHRvIG1vcmUgZWFzaWx5IGNvbGxl Y3QgdGhlIHVzZXJzIGNvbnNlbnQuJm5ic3A7PGRpdj48YnI+PC9kaXY+PGRpdj5PbmNlIHlvdSBn ZXQgdGhlIHRva2VucyBiYXNlZCBvbiB0aGF0IGNvbnNlbnQsIGV2ZXJ5dGhpbmcgaXMgJ1JFU1Rm dWwnPC9kaXY+PGJyPjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxi cj5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBVc2luZyBPQXV0aCB0byBnZXQgYSBKV1QvU0FNTCB0 b2tlbjxicj5Gcm9tOiBMZXdpcyBBZGFtLUNBTDAyMiAmbHQ7QWRhbS5MZXdpc0Btb3Rvcm9sYXNv bHV0aW9ucy5jb20mZ3Q7PGJyPlRvOiBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdHJlLm9y ZyZndDs8YnI+Q0M6IFJlOiBbT0FVVEgtV0ddIFVzaW5nIE9BdXRoIHRvIGdldCBhIEpXVC9TQU1M IHRva2VuPGJyPjxicj48YnI+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6b2xpdmUiPkhpIEp1 c3Rpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOm9saXZlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOm9saXZlIj5UaGVyZSBpcyBvbmUgdGhpbmcgSSBoYXZlIG5vdCB1bmRlcnN0b29kIGFi b3V0IHRoZSB3aG9sZSBleHRlcm5hbCBicm93c2VyIHZzLiBlbWJlZGRlZCBicm93c2VyIGd1aWRh bmNlIOKApiBhbmQgdGhhdCBpcywgd2h5IGlzICo8Yj5hbnk8L2I+KiBicm93c2VyIG5lZWRlZD8m bmJzcDsgSmF2YSBmb3IgZXhhbXBsZSBoYXMgYW4gSFRUUCBsaWJyYXJ5LAogYW5kIE9BdXRoIGlz IFJFU1RmdWwuJm5ic3A7IFNvIHdoeSBpcyBpdCBuZWNlc3NhcnkgdG8gcmVxdWlyZSB0aGUgd2Vi IGJyb3dzZXIgYXQgYWxsLCB3aGV0aGVyIGV4dGVybmFsIG9yIGVtYmVkZGVkPyZuYnNwOyBXaHkg Y2Fu4oCZdCBteSBuYXRpdmUgY2xpZW50IG1ha2UgUkVTVGZ1bCBBUEkgY2FsbHMgdG8gdGhlIEFT IGFuZCBSUyBuYXRpdmVseT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOm9saXZlIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOm9saXZlIj5UeCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOm9saXZl Ij5hZGFtPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpvbGl2ZSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPgo8ZGl2Pgo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4g SnVzdGluIFJpY2hlciBbbWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnXQo8YnI+CjxiPlNlbnQ6PC9i PiBGcmlkYXksIEFwcmlsIDEzLCAyMDEyIDExOjM4IEFNPGJyPgo8Yj5Ubzo8L2I+IExld2lzIEFk YW0tQ0FMMDIyPGJyPgo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPgo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gVXNpbmcgT0F1dGggdG8gZ2V0IGEgSldUL1NBTUwgdG9rZW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBtb2JpbGUgZGV2 aWNlIGhhcyBhIHdlYiBicm93c2VyIChzdWNoIGFzIGEgc21hcnQgcGhvbmUpLCB0aGVuIHRoaXMg aXMgcHJldHR5IGVhc3ksIGFuZCB5b3UndmUgZ290IGEgY291cGxlIG9mIG9wdGlvbnMuPGJyPgo8 YnI+Ck9uZSBvZiB0aGUgYmVzdCBvcHRpb25zIHdoZW4gdGhlIHRva2VuIGlzIG9uIGJlaGFsZiBv ZiBhbiBlbmQgdXNlciBpcywgaW4gbXkgb3BpbmlvbiwgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9u IGNvZGUgZmxvdyBsaWtlIHRoaXM6IEZpcnN0LCByZWdpc3RlciB3aGF0J3MgY2FsbGVkIGEgInB1 YmxpYyBjbGllbnQiIHdpdGggeW91ciBzZXJ2ZXIgLS0gc28geW91J2xsIGdldCBhbiBJRCBidXQg bm90IGEgY2xpZW50IHNlY3JldC4gV2l0aCB0aGF0IGNsaWVudAogSUQsIHJlZ2lzdGVyIGEgY3Vz dG9tLXNjaGVtZSBjYWxsYmFjayBVUkksIGxpa2UgIm15YXBwOi8vb2F1dGhjYWxsYmFjayIsIGFu ZCByZWdpc3RlciB5b3VyIGFwcCBvbiB0aGUgZGV2aWNlIGFzIHRoZSBoYW5kbGVyIGZvciAibXlh cHAiLgo8YnI+Cjxicj4KSW4geW91ciBhcHBsaWNhdGlvbiwgdG8gc3RhcnQgdGhpbmdzIG9mZiwg eW91IGZpcmUgb2ZmIGEgd2ViIGJyb3dzZXIgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3Mg YXV0aG9yaXphdGlvbiBlbmRwb2ludC4gVGhlIHVzZXIgbG9ncyBpbiB0byB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgdGhyb3VnaCB0aGUgd2ViIGJyb3dzZXIsIGFwcHJvdmVzIHRoaXMgY29weSBv ZiB5b3VyIGFwcCwgYW5kIGdldHMgcmVkaXJlY3RlZCB0byAibXlhcHA6Ly9vYXV0aGNhbGxiYWNr P2NvZGU9YmFzZGYxMzIiLgogWW91ciBhcHAgZ3JhYnMgdGhlICJteWFwcDovLyIgdXJsIGFuZCBw bHVja3MgdGhlIGF1dGhvcml6YXRpb24gY29kZSBvZmYgdGhlIGVuZCBvZiBpdC4gWW91ciBhcHAg dGhlbiB0YWtlcyB0aGF0IGNvZGUgYW5kIHNlbmRzIGl0IGluIHRoZSBiYWNrZ3JvdW5kIHRvIHRo ZSB0b2tlbiBlbmRwb2ludCB0byBleGNoYW5nZSBmb3IgYSB0b2tlbi4KPGJyPgo8YnI+ClNvbWUg a2V5IHBvaW50czogPGJyPgo8YnI+CjEpIFlvdSBuZWVkIHRvIGhhdmUgYWNjZXNzIHRvIGEgd2Vi IGJyb3dzZXIgb24gdGhlIHBsYXRmb3JtLCBhbmQgaXQncyBjb25zaWRlcmVkIGJlc3QgcHJhY3Rp Y2UgdG8gcHVzaCB0aGUgdXNlciB0byB0aGUgZXh0ZXJuYWwgYnJvd3NlciBhcHBsaWNhdGlvbiBv biB0aGUgcGxhdGZvcm0gaW5zdGVhZCBvZiBlbWJlZGRpbmcgb25lLiBUaGVyZSBhcmUgYSBjb3Vw bGUgcGFyYWdyYXBocyBpbiB0aGUgc3BlYydzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zCiBzZWN0 aW9uIHRoYXQgdGFsayBhYm91dCB0aGlzLjxicj4KMikgWW91ciBhcHAgaXMgInB1YmxpYyIgYmVj YXVzZSB5b3UgY2FuJ3QgcHVibGlzaCBpdCB3aXRoIGEgc2VjcmV0IGF0IGNvbmZpZ3VyYXRpb24g dGltZS4gSXQgY2FuLCBob3dldmVyLCBrZWVwIHRoZSB0b2tlbnMgc2VjcmV0IGF0IHJ1bnRpbWUu PGJyPgozKSBZb3UgbmVlZCB0byBiZSB2ZXJ5IGNhcmVmdWwgd2l0aCBob3cgeW91IHN0b3JlIHRo ZSB0b2tlbnMgb24gdGhlIGRldmljZSAtLSB0aGV5IG5lZWQgdG8gYmUgaW4gYSB0cnVzdGVkIHNw YWNlIHdoZXJlIG90aGVyIGFwcHMgb24gdGhlIGRldmljZSBjYW4ndCBzbmlmZiB0aGVtIG91dC48 YnI+CjQpIEFub3RoZXIgYXBwIGNhbiB0cnkgdG8gcmVnaXN0ZXIgIm15YXBwOi8vIiBhbmQgaW50 ZXJjZXB0IHlvdXIgY29kZSBvbiB0aGUgd2F5IHRocm91Z2gsIHNvIG1ha2Ugc3VyZSB5b3VyIGNv ZGVzIGFyZSBhbGwgb25lIHRpbWUgdXNlIGFuZCBzaG9ydCBsaXZlZC48YnI+Cjxicj4KTm9uZSBv ZiB0aGlzIGlzIGp1c3QgdGhlb3JldGljYWxseSBwb3NzaWJsZSwgcGVvcGxlIGFyZSBkb2luZyBp dCB0b2RheS4gV2hhdCBsaWJyYXJpZXMgYW5kIHN0dWZmIHlvdSdkIGJlIGFmdGVyIGRlcGVuZHMg d2hvbGx5IG9uIHlvdXIgcGxhdGZvcm0gKGJvdGggc2VydmVyIGFuZCBjbGllbnQgc2lkZSkuCjxi cj4KPGJyPgombmJzcDstLSBKdXN0aW48YnI+Cjxicj4KT24gMDQvMTIvMjAxMiAwMzowMSBQTSwg TGV3aXMgQWRhbS1DQUwwMjIgd3JvdGU6IDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SGkgYWxsLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPknigJl2ZSBiZWVuIHRhbGtpbmcgdG8gc29tZSBv ZiB5b3Ugb2ZmIGxpbmUgYWJvdXQgdGhpcyBhbHJlYWR5LCBidXQgSSBuZWVkIHNvbWUgaGVscCBp biB0ZXJtcyBvZiBpbXBsZW1lbnRhdGlvbi4mbmJzcDsgSSB3b3VsZCBsaWtlIHRvIHVzZSBPQXV0 aCBhcyBhIG1lYW5zIHRvIGdldCBlaXRoZXIgYSBKV1Qgb3IgU0FNTCB0b2tlbiB0byBhIGNsaWVu dCBydW5uaW5nIG9uCiBhIGhhbmRoZWxkIGRldmljZS4mbmJzcDsgVGhpcyBpcyBzb21ldGhpbmcg dGhhdCBJ4oCZbSBsb29raW5nIHRvIHByb3RvdHlwZSAoYXMgcGFydCBvZiBhIGxhcmdlciBwcm9q ZWN0KSBiZWdpbm5pbmcgdGhpcyB3ZWVrLiZuYnNwOyBTbywgaXQgaXMgaW1wb3J0YW50IHRvIG1l IHRvIHVuZGVyc3RhbmQgdGhlIGRpdmlkZSBiZXR3ZWVuIHdoYXQgaXMgdGhlb3JldGljYWxseSBw b3NzaWJsZSBhbmQgd2hhdCBpcyBhY3R1YWxseSBwb3NzaWJsZS48L3NwYW4+PG86cD48L286cD48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbnlib2R5IGF3YXJlIG9mIGFueSBpbXBsZW1lbnRhdGlv bnMgb3V0IHRoZXJlLCBlaXRoZXIgdmVuZG9yIG9yIG9wZW4gc291cmNlLCB0aGF0IEkgY2FuIHVz ZSBmb3IgdGhpcz88L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UeCE8 YnI+CmFkYW08L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPgo8YnI+Cjxicj4KPG86cD48L286cD48L3Nw YW4+PC9wPgo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPG86cD48L286cD48L3ByZT4KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv cHJlPgo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8 L2E+PG86cD48L286cD48L3ByZT4KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8 L2Rpdj4KCjwvYm9keT4= ----_com.android.email_73935595691294-- From bcampbell@pingidentity.com Thu Apr 19 15:08:51 2012 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 46F8811E80CB for ; Thu, 19 Apr 2012 15:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XMFzaXcVWTW for ; Thu, 19 Apr 2012 15:08:49 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 47CA611E80BB for ; Thu, 19 Apr 2012 15:08:48 -0700 (PDT) Received: from mail-vb0-f42.google.com ([209.85.212.42]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKT5CM7/57B7+m3U3+OnxHlhz7LUSLk0Ew@postini.com; Thu, 19 Apr 2012 15:08:48 PDT Received: by vbjk13 with SMTP id k13so6283780vbj.15 for ; Thu, 19 Apr 2012 15:08:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=oWWzsF9wi6d0WaRtw6C16TojLmUwgSCbJEqUKNvLIBQ=; b=pcUna7WF5D4s36iUdoYZP6fdI1wrl2465Oe6IXjmHJ3W1apYDs/WEcyJuCjyJQkbHm wHDxJr5JyKbFdOhUvZTJWlSNRgy4KPfddGbKCqIV+Zs5GNSv7yo4vwDIwSlcDQ0QdtC+ 1RUi3xVHRPBYa2aADVLLf07OEoH+qyu+bou8QagjDP0IW0UgKstQnAI7RjFIVwiosv2o /Ju1cFl1Sgx+aCZOLi9UC3NdeePJp5FTAD7EcEURnjWUY/+v1v7B2CzYpWMm/oGb7gZb //eLBvvVUYAJjRlZFWqz9o/YXZL9PliaLOdsNrpEe+XMmV5OPSHyEiKvDC6nka/sY3j9 3qug== Received: by 10.220.153.84 with SMTP id j20mr2104868vcw.3.1334873326673; Thu, 19 Apr 2012 15:08:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.38.104 with HTTP; Thu, 19 Apr 2012 15:08:16 -0700 (PDT) In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9090519@CH1PRD0410MB369.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A906E74E@CH1PRD0410MB369.namprd04.prod.outlook.com> <4F885680.5090801@mitre.org> <59E470B10C4630419ED717AC79FCF9A9090519@CH1PRD0410MB369.namprd04.prod.outlook.com> From: Brian Campbell Date: Thu, 19 Apr 2012 16:08:16 -0600 Message-ID: To: Lewis Adam-CAL022 Content-Type: multipart/alternative; boundary=f46d043c7c8874dec404be0f6a29 X-Gm-Message-State: ALoCoQnvLUPMudpHyRfONXdmi5g0DNNqXvYSuRcWOOcOZ9HFmNbUYTvUaWr8rdjcHC/cA5/F8uHv Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Thu, 19 Apr 2012 22:08:51 -0000 --f46d043c7c8874dec404be0f6a29 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A browser isn't required. The browser based flows are pretty common with OAuth but they are certainly not the only way to get a token. The resource owner credentials and client credentials grant types are both involve only direct communication between the client and the AS. And there are also the SAML and JWT grants that allow a client to get an access token directly from an AS without a browser being involved. On Thu, Apr 19, 2012 at 3:37 PM, Lewis Adam-CAL022 < Adam.Lewis@motorolasolutions.com> wrote: > Hi Justin,**** > > ** ** > > There is one thing I have not understood about the whole external browser > vs. embedded browser guidance =85 and that is, why is **any** browser > needed? Java for example has an HTTP library, and OAuth is RESTful. So > why is it necessary to require the web browser at all, whether external o= r > embedded? Why can=92t my native client make RESTful API calls to the AS = and > RS natively?**** > > ** ** > > Tx!**** > > adam**** > > ** ** > > *From:* Justin Richer [mailto:jricher@mitre.org] > *Sent:* Friday, April 13, 2012 11:38 AM > *To:* Lewis Adam-CAL022 > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token**** > > ** ** > > If the mobile device has a web browser (such as a smart phone), then this > is pretty easy, and you've got a couple of options. > > One of the best options when the token is on behalf of an end user is, in > my opinion, to use the authorization code flow like this: First, register > what's called a "public client" with your server -- so you'll get an ID b= ut > not a client secret. With that client ID, register a custom-scheme callba= ck > URI, like "myapp://oauthcallback", and register your app on the device as > the handler for "myapp". > > In your application, to start things off, you fire off a web browser to > the authorization server's authorization endpoint. The user logs in to th= e > authorization server through the web browser, approves this copy of your > app, and gets redirected to "myapp://oauthcallback?code=3Dbasdf132". Your= app > grabs the "myapp://" url and plucks the authorization code off the end of > it. Your app then takes that code and sends it in the background to the > token endpoint to exchange for a token. > > Some key points: > > 1) You need to have access to a web browser on the platform, and it's > considered best practice to push the user to the external browser > application on the platform instead of embedding one. There are a couple > paragraphs in the spec's security considerations section that talk about > this. > 2) Your app is "public" because you can't publish it with a secret at > configuration time. It can, however, keep the tokens secret at runtime. > 3) You need to be very careful with how you store the tokens on the devic= e > -- they need to be in a trusted space where other apps on the device can'= t > sniff them out. > 4) Another app can try to register "myapp://" and intercept your code on > the way through, so make sure your codes are all one time use and short > lived. > > None of this is just theoretically possible, people are doing it today. > What libraries and stuff you'd be after depends wholly on your platform > (both server and client side). > > -- Justin > > On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote: **** > > Hi all,**** > > **** > > I=92ve been talking to some of you off line about this already, but I nee= d > some help in terms of implementation. I would like to use OAuth as a mea= ns > to get either a JWT or SAML token to a client running on a handheld > device. This is something that I=92m looking to prototype (as part of a > larger project) beginning this week. So, it is important to me to > understand the divide between what is theoretically possible and what is > actually possible.**** > > **** > > Anybody aware of any implementations out there, either vendor or open > source, that I can use for this?**** > > **** > > Tx! > adam**** > > > > > **** > > _______________________________________________**** > > 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 > > --f46d043c7c8874dec404be0f6a29 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A browser isn't required. The browser based flows are pretty common wit= h OAuth but they are certainly not the only way to get a token.

The= resource owner credentials and client credentials grant types are both inv= olve only direct communication between the client and the AS. And there are= also the SAML and JWT grants that allow a client to get an access token di= rectly from an AS without a browser being involved.

On Thu, Apr 19, 2012 at 3:37 PM, Lewis Adam-= CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Just= in,

= =A0

There i= s one thing I have not understood about the whole external browser vs. embe= dded browser guidance =85 and that is, why is *any* browser needed?= =A0 Java for example has an HTTP library, and OAuth is RESTful.=A0 So why is it necessary to require the web browser= at all, whether external or embedded?=A0 Why can=92t my native client make= RESTful API calls to the AS and RS natively?

= =A0

Tx!<= /u>

adam=

= =A0

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, April 13, 2012 11:38 AM
To: Lewis Adam-CAL022
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

=A0

If the mobile device has a web browser (such as a sm= art phone), then this is pretty easy, and you've got a couple of option= s.

One of the best options when the token is on behalf of an end user is, in m= y opinion, to use the authorization code flow like this: First, register wh= at's called a "public client" with your server -- so you'= ll get an ID but not a client secret. With that client ID, register a custom-scheme callback URI, like "myapp://oauthcallbac= k", and register your app on the device as the handler for "myapp= ".

In your application, to start things off, you fire off a web browser to the= authorization server's authorization endpoint. The user logs in to the= authorization server through the web browser, approves this copy of your a= pp, and gets redirected to "myapp://oauthcallback?code=3Dbasdf132"= ;. Your app grabs the "myapp://" url and plucks the authorization c= ode off the end of it. Your app then takes that code and sends it in the ba= ckground to the token endpoint to exchange for a token.

Some key points:

1) You need to have access to a web browser on the platform, and it's c= onsidered best practice to push the user to the external browser applicatio= n on the platform instead of embedding one. There are a couple paragraphs i= n the spec's security considerations section that talk about this.
2) Your app is "public" because you can't publish it with a s= ecret at configuration time. It can, however, keep the tokens secret at run= time.
3) You need to be very careful with how you store the tokens on the device = -- they need to be in a trusted space where other apps on the device can= 9;t sniff them out.
4) Another app can try to register "myapp://" and intercept your = code on the way through, so make sure your codes are all one time use and s= hort lived.

None of this is just theoretically possible, people are doing it today. Wha= t libraries and stuff you'd be after depends wholly on your platform (b= oth server and client side).

=A0-- Justin

On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote:

Hi all,

=A0

I=92ve been talking= to some of you off line about this already, but I need some help in terms = of implementation.=A0 I would like to use OAuth as a means to get either a = JWT or SAML token to a client running on a handheld device.=A0 This is something that I=92m looking to prototype (a= s part of a larger project) beginning this week.=A0 So, it is important to = me to understand the divide between what is theoretically possible and what= is actually possible.

=A0

Anybody aware of an= y implementations out there, either vendor or open source, that I can use f= or this?

=A0

Tx!
adam




_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth

=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--f46d043c7c8874dec404be0f6a29-- From Adam.Lewis@motorolasolutions.com Thu Apr 19 15:12:11 2012 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 55D8721F85D2 for ; Thu, 19 Apr 2012 15:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uspqk5Bo3qG3 for ; Thu, 19 Apr 2012 15:12:10 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id D315521F85AA for ; Thu, 19 Apr 2012 15:12:09 -0700 (PDT) Received: from mail71-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 22:12:09 +0000 Received: from mail71-va3 (localhost [127.0.0.1]) by mail71-va3-R.bigfish.com (Postfix) with ESMTP id 0AF4E3A037C for ; Thu, 19 Apr 2012 22:12:09 +0000 (UTC) X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI9371Ic89bhc857h98dK14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25h) X-Forefront-Antispam-Report: CIP:192.160.210.20; KIP:(null); UIP:(null); IPV:NLI; H:il27msg01.am.mot-solutions.com; RD:il27msg01.mot-solutions.com; EFVD:NLI Received-SPF: pass (mail71-va3: domain of motorolasolutions.com designates 192.160.210.20 as permitted sender) client-ip=192.160.210.20; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il27msg01.am.mot-solutions.com ; olutions.com ; Received: from mail71-va3 (localhost.localdomain [127.0.0.1]) by mail71-va3 (MessageSwitch) id 133487352795548_29149; Thu, 19 Apr 2012 22:12:07 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.253]) by mail71-va3.bigfish.com (Postfix) with ESMTP id 10A5438006E for ; Thu, 19 Apr 2012 22:12:07 +0000 (UTC) Received: from il27msg01.am.mot-solutions.com (192.160.210.20) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 22:12:04 +0000 Received: from il27msg01.am.mot-solutions.com (ct11vts01.am.mot.com [10.177.16.159]) by il27msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3JMNiaD028030 for ; Thu, 19 Apr 2012 17:23:44 -0500 (CDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by il27msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3JMNgFf028027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Apr 2012 17:23:43 -0500 (CDT) Received: from mail120-db3-R.bigfish.com (10.3.81.229) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 22:11:55 +0000 Received: from mail120-db3 (localhost [127.0.0.1]) by mail120-db3-R.bigfish.com (Postfix) with ESMTP id D32213C04E5 for ; Thu, 19 Apr 2012 22:11:55 +0000 (UTC) Received: from mail120-db3 (localhost.localdomain [127.0.0.1]) by mail120-db3 (MessageSwitch) id 1334873512269357_22253; Thu, 19 Apr 2012 22:11:52 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.237]) by mail120-db3.bigfish.com (Postfix) with ESMTP id 348EF1A05E3; Thu, 19 Apr 2012 22:11:52 +0000 (UTC) Received: from BL2PRD0410HT002.namprd04.prod.outlook.com (157.56.240.85) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 22:11:51 +0000 Received: from BL2PRD0410MB363.namprd04.prod.outlook.com ([169.254.3.84]) by BL2PRD0410HT002.namprd04.prod.outlook.com ([10.255.99.37]) with mapi id 14.16.0143.004; Thu, 19 Apr 2012 22:11:51 +0000 From: Lewis Adam-CAL022 To: Paul Madsen , "jricher@mitre.org" Thread-Topic: [OAUTH-WG] Using OAuth to get a JWT/SAML token Thread-Index: AQHNHng8daEyP8MLBE2BQ7YBnfHZD5ais9Cw Date: Thu, 19 Apr 2012 22:11:50 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9097843@BL2PRD0410MB363.namprd04.prod.outlook.com> References: <5jrlua1y80mdxtvpmygf5tp1.1334872982862@email.android.com> In-Reply-To: <5jrlua1y80mdxtvpmygf5tp1.1334872982862@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.9.149] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9097843BL2PRD0410MB363na_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0410HT002.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False;00160000;True;; X-OrganizationHeadersPreserved: BL2PRD0410HT002.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MITRE.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Thu, 19 Apr 2012 22:12:11 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9097843BL2PRD0410MB363na_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KU28gYnkgc2F5aW5nIOKAmG1vcmUgZWFzaWx54oCZIHRoZW4gdGhlcmUgaXMg bm90aGluZyByZWFsbHkgaW5oZXJlbnRseSBwcmV2ZW50aW5nIGEgbmF0aXZlIGltcGxlbWVudGF0 aW9uIGZyb20gbWFraW5nIHRoZSBIVFRQIGNhbGxzIHRvIHRoZSBBUyBkaXJlY3RseSwgcmlnaHQ/ DQoNCk15IHVzZSBjYXNlcyBhcmUgYSBiaXQgYXR5cGljYWwgZnJvbSB0aGUgd2ViIHNlcnZpY2Ug ZHJpdmVuIG1vZGVscyB0aGF0IHlvdSBndXlzIGFyZSBzb2x2aW5nLCBidXQgSSB0aGluayB0aGUg dGVjaG5vbG9neSBzaG91bGQgc3RpbGwgZml0LiAgVGhlIFJTIHRoYXQgbXkgbmF0aXZlIGNsaWVu dCBpcyB0YWxraW5nIHRvIGlzICpub3QqIGEgd2ViIHNlcnZpY2UgKEkgcmVhbGl6ZSBJ4oCZbSBu b3Qgb3V0c2lkZSB0aGUgYm91bmRzIG9mIE9BdXRoLXByb3BlciBoZXJlKS4gIEJ1dCBpdOKAmXMg ZWFzeSBlbm91Z2ggZm9yIG1lIHRvIHVzZSBPQXV0aCB0byBnZXQgYW4gYWNjZXNzLXRva2VuIGFu ZCBpbmNsdWRlIHRoYXQgaW4gbXkgbWVzc2FnZSBiZXR3ZWVuIG15IG5hdGl2ZSBjbGllbnQgYW5k IG15IChub24td2ViIHNlcnZpY2UpIFJTLiAgTXkgUlMgY2FuIHN0aWxsIGludHJvc3BlY3QgaXQg YWdhaW5zdCBhbiBPQXV0aCBTVFMuDQoNClRoZXNlIG5hdGl2ZSBhcHBzIEnigJltIHNwZWFraW5n IG9mLCBJ4oCZbSBhdHRlbXB0aW5nIHRvIHJldHJvZml0IHdpdGggT0F1dGgsIGFuZCB0b2RheSB0 aGV5IGFscmVhZHkgaGF2ZSBuYXRpdmUgaW50ZXJmYWNlcyBmb3IgYWNjZXB0aW5nIGEgdXNlcuKA mXMgbG9nb24gYW5kIGNyZWRlbnRpYWxzIOKApiB0byBwb3AgYSB3ZWIgYnJvd3NlciB3b3VsZCBu b3QgYmUgaW50dWl0aXZlIHRvIG15IGN1c3RvbWVyIGJhc2UuDQoNCkkgZG9u4oCZdCBzZWUgYW55 IHJlYXNvbiBJIGNhbuKAmXQgaW1wbGVtZW50IHRoaXMgbmF0aXZlIHdpdGhpbiBteSBjbGllbnQs IGp1c3Qgd2FudCB0byBiZSBzdXJlIHNpbmNlIHRoZSBicm93c2VyIHRyaWNrIGlzIHN1Y2ggYSBw cm9taW5lbnQgdHJlbmQsIEkgd2FudCB0byBiZSBzdXJlIHRoYXQgdGhlcmXigJlzIG5vIGdvdGNo YSBJIGhhdmVu4oCZdCB0aG91Z2h0IG9mLg0KDQpUeCENCmFkYW0NCg0KRnJvbTogUGF1bCBNYWRz ZW4gW21haWx0bzpwYXVsLm1hZHNlbkBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwg MTksIDIwMTIgNTowMyBQTQ0KVG86IExld2lzIEFkYW0tQ0FMMDIyOyBqcmljaGVyQG1pdHJlLm9y Zw0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBVc2luZyBPQXV0 aCB0byBnZXQgYSBKV1QvU0FNTCB0b2tlbg0KDQpVc2luZyB0aGUgYnJvd3NlciBhcyBwYXJ0IG9m IHRoZSBBUyBpbnRlcmFjdGlvbiBhbGxvd3MgeW91IHRvIG1vcmUgZWFzaWx5IGNvbGxlY3QgdGhl IHVzZXJzIGNvbnNlbnQuDQoNCk9uY2UgeW91IGdldCB0aGUgdG9rZW5zIGJhc2VkIG9uIHRoYXQg Y29uc2VudCwgZXZlcnl0aGluZyBpcyAnUkVTVGZ1bCcNCg0KDQoNCi0tLS0tLS0tIE9yaWdpbmFs IG1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFVzaW5nIE9BdXRoIHRv IGdldCBhIEpXVC9TQU1MIHRva2VuDQpGcm9tOiBMZXdpcyBBZGFtLUNBTDAyMiA8QWRhbS5MZXdp c0Btb3Rvcm9sYXNvbHV0aW9ucy5jb20+DQpUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXRy ZS5vcmc+DQpDQzogUmU6IFtPQVVUSC1XR10gVXNpbmcgT0F1dGggdG8gZ2V0IGEgSldUL1NBTUwg dG9rZW4NCg0KSGkgSnVzdGluLA0KDQpUaGVyZSBpcyBvbmUgdGhpbmcgSSBoYXZlIG5vdCB1bmRl cnN0b29kIGFib3V0IHRoZSB3aG9sZSBleHRlcm5hbCBicm93c2VyIHZzLiBlbWJlZGRlZCBicm93 c2VyIGd1aWRhbmNlIOKApiBhbmQgdGhhdCBpcywgd2h5IGlzICphbnkqIGJyb3dzZXIgbmVlZGVk PyAgSmF2YSBmb3IgZXhhbXBsZSBoYXMgYW4gSFRUUCBsaWJyYXJ5LCBhbmQgT0F1dGggaXMgUkVT VGZ1bC4gIFNvIHdoeSBpcyBpdCBuZWNlc3NhcnkgdG8gcmVxdWlyZSB0aGUgd2ViIGJyb3dzZXIg YXQgYWxsLCB3aGV0aGVyIGV4dGVybmFsIG9yIGVtYmVkZGVkPyAgV2h5IGNhbuKAmXQgbXkgbmF0 aXZlIGNsaWVudCBtYWtlIFJFU1RmdWwgQVBJIGNhbGxzIHRvIHRoZSBBUyBhbmQgUlMgbmF0aXZl bHk/DQoNClR4IQ0KYWRhbQ0KDQpGcm9tOiBKdXN0aW4gUmljaGVyIFttYWlsdG86anJpY2hlckBt aXRyZS5vcmddDQpTZW50OiBGcmlkYXksIEFwcmlsIDEzLCAyMDEyIDExOjM4IEFNDQpUbzogTGV3 aXMgQWRhbS1DQUwwMjINCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1X R10gVXNpbmcgT0F1dGggdG8gZ2V0IGEgSldUL1NBTUwgdG9rZW4NCg0KSWYgdGhlIG1vYmlsZSBk ZXZpY2UgaGFzIGEgd2ViIGJyb3dzZXIgKHN1Y2ggYXMgYSBzbWFydCBwaG9uZSksIHRoZW4gdGhp cyBpcyBwcmV0dHkgZWFzeSwgYW5kIHlvdSd2ZSBnb3QgYSBjb3VwbGUgb2Ygb3B0aW9ucy4NCg0K T25lIG9mIHRoZSBiZXN0IG9wdGlvbnMgd2hlbiB0aGUgdG9rZW4gaXMgb24gYmVoYWxmIG9mIGFu IGVuZCB1c2VyIGlzLCBpbiBteSBvcGluaW9uLCB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29k ZSBmbG93IGxpa2UgdGhpczogRmlyc3QsIHJlZ2lzdGVyIHdoYXQncyBjYWxsZWQgYSAicHVibGlj IGNsaWVudCIgd2l0aCB5b3VyIHNlcnZlciAtLSBzbyB5b3UnbGwgZ2V0IGFuIElEIGJ1dCBub3Qg YSBjbGllbnQgc2VjcmV0LiBXaXRoIHRoYXQgY2xpZW50IElELCByZWdpc3RlciBhIGN1c3RvbS1z Y2hlbWUgY2FsbGJhY2sgVVJJLCBsaWtlICJteWFwcDovL29hdXRoY2FsbGJhY2siLCBhbmQgcmVn aXN0ZXIgeW91ciBhcHAgb24gdGhlIGRldmljZSBhcyB0aGUgaGFuZGxlciBmb3IgIm15YXBwIi4N Cg0KSW4geW91ciBhcHBsaWNhdGlvbiwgdG8gc3RhcnQgdGhpbmdzIG9mZiwgeW91IGZpcmUgb2Zm IGEgd2ViIGJyb3dzZXIgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3MgYXV0aG9yaXphdGlv biBlbmRwb2ludC4gVGhlIHVzZXIgbG9ncyBpbiB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg dGhyb3VnaCB0aGUgd2ViIGJyb3dzZXIsIGFwcHJvdmVzIHRoaXMgY29weSBvZiB5b3VyIGFwcCwg YW5kIGdldHMgcmVkaXJlY3RlZCB0byAibXlhcHA6Ly9vYXV0aGNhbGxiYWNrP2NvZGU9YmFzZGYx MzIiLiBZb3VyIGFwcCBncmFicyB0aGUgIm15YXBwOi8vIiB1cmwgYW5kIHBsdWNrcyB0aGUgYXV0 aG9yaXphdGlvbiBjb2RlIG9mZiB0aGUgZW5kIG9mIGl0LiBZb3VyIGFwcCB0aGVuIHRha2VzIHRo YXQgY29kZSBhbmQgc2VuZHMgaXQgaW4gdGhlIGJhY2tncm91bmQgdG8gdGhlIHRva2VuIGVuZHBv aW50IHRvIGV4Y2hhbmdlIGZvciBhIHRva2VuLg0KDQpTb21lIGtleSBwb2ludHM6DQoNCjEpIFlv dSBuZWVkIHRvIGhhdmUgYWNjZXNzIHRvIGEgd2ViIGJyb3dzZXIgb24gdGhlIHBsYXRmb3JtLCBh bmQgaXQncyBjb25zaWRlcmVkIGJlc3QgcHJhY3RpY2UgdG8gcHVzaCB0aGUgdXNlciB0byB0aGUg ZXh0ZXJuYWwgYnJvd3NlciBhcHBsaWNhdGlvbiBvbiB0aGUgcGxhdGZvcm0gaW5zdGVhZCBvZiBl bWJlZGRpbmcgb25lLiBUaGVyZSBhcmUgYSBjb3VwbGUgcGFyYWdyYXBocyBpbiB0aGUgc3BlYydz IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdGhhdCB0YWxrIGFib3V0IHRoaXMuDQoy KSBZb3VyIGFwcCBpcyAicHVibGljIiBiZWNhdXNlIHlvdSBjYW4ndCBwdWJsaXNoIGl0IHdpdGgg YSBzZWNyZXQgYXQgY29uZmlndXJhdGlvbiB0aW1lLiBJdCBjYW4sIGhvd2V2ZXIsIGtlZXAgdGhl IHRva2VucyBzZWNyZXQgYXQgcnVudGltZS4NCjMpIFlvdSBuZWVkIHRvIGJlIHZlcnkgY2FyZWZ1 bCB3aXRoIGhvdyB5b3Ugc3RvcmUgdGhlIHRva2VucyBvbiB0aGUgZGV2aWNlIC0tIHRoZXkgbmVl ZCB0byBiZSBpbiBhIHRydXN0ZWQgc3BhY2Ugd2hlcmUgb3RoZXIgYXBwcyBvbiB0aGUgZGV2aWNl IGNhbid0IHNuaWZmIHRoZW0gb3V0Lg0KNCkgQW5vdGhlciBhcHAgY2FuIHRyeSB0byByZWdpc3Rl ciAibXlhcHA6Ly8iIGFuZCBpbnRlcmNlcHQgeW91ciBjb2RlIG9uIHRoZSB3YXkgdGhyb3VnaCwg c28gbWFrZSBzdXJlIHlvdXIgY29kZXMgYXJlIGFsbCBvbmUgdGltZSB1c2UgYW5kIHNob3J0IGxp dmVkLg0KDQpOb25lIG9mIHRoaXMgaXMganVzdCB0aGVvcmV0aWNhbGx5IHBvc3NpYmxlLCBwZW9w bGUgYXJlIGRvaW5nIGl0IHRvZGF5LiBXaGF0IGxpYnJhcmllcyBhbmQgc3R1ZmYgeW91J2QgYmUg YWZ0ZXIgZGVwZW5kcyB3aG9sbHkgb24geW91ciBwbGF0Zm9ybSAoYm90aCBzZXJ2ZXIgYW5kIGNs aWVudCBzaWRlKS4NCg0KIC0tIEp1c3Rpbg0KDQpPbiAwNC8xMi8yMDEyIDAzOjAxIFBNLCBMZXdp cyBBZGFtLUNBTDAyMiB3cm90ZToNCkhpIGFsbCwNCg0KSeKAmXZlIGJlZW4gdGFsa2luZyB0byBz b21lIG9mIHlvdSBvZmYgbGluZSBhYm91dCB0aGlzIGFscmVhZHksIGJ1dCBJIG5lZWQgc29tZSBo ZWxwIGluIHRlcm1zIG9mIGltcGxlbWVudGF0aW9uLiAgSSB3b3VsZCBsaWtlIHRvIHVzZSBPQXV0 aCBhcyBhIG1lYW5zIHRvIGdldCBlaXRoZXIgYSBKV1Qgb3IgU0FNTCB0b2tlbiB0byBhIGNsaWVu dCBydW5uaW5nIG9uIGEgaGFuZGhlbGQgZGV2aWNlLiAgVGhpcyBpcyBzb21ldGhpbmcgdGhhdCBJ 4oCZbSBsb29raW5nIHRvIHByb3RvdHlwZSAoYXMgcGFydCBvZiBhIGxhcmdlciBwcm9qZWN0KSBi ZWdpbm5pbmcgdGhpcyB3ZWVrLiAgU28sIGl0IGlzIGltcG9ydGFudCB0byBtZSB0byB1bmRlcnN0 YW5kIHRoZSBkaXZpZGUgYmV0d2VlbiB3aGF0IGlzIHRoZW9yZXRpY2FsbHkgcG9zc2libGUgYW5k IHdoYXQgaXMgYWN0dWFsbHkgcG9zc2libGUuDQoNCkFueWJvZHkgYXdhcmUgb2YgYW55IGltcGxl bWVudGF0aW9ucyBvdXQgdGhlcmUsIGVpdGhlciB2ZW5kb3Igb3Igb3BlbiBzb3VyY2UsIHRoYXQg SSBjYW4gdXNlIGZvciB0aGlzPw0KDQpUeCENCmFkYW0NCg0KDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QN Cg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_59E470B10C4630419ED717AC79FCF9A9097843BL2PRD0410MB363na_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjpvbGl2ZTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3Jt YWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpvbGl2ZSI+SGkgUGF1bCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPlNvIGJ5 IHNheWluZyDigJhtb3JlIGVhc2lseeKAmSB0aGVuIHRoZXJlIGlzIG5vdGhpbmcgcmVhbGx5IGlu aGVyZW50bHkgcHJldmVudGluZyBhIG5hdGl2ZSBpbXBsZW1lbnRhdGlvbiBmcm9tIG1ha2luZyB0 aGUgSFRUUCBjYWxscyB0byB0aGUgQVMgZGlyZWN0bHksIHJpZ2h0PzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6b2xpdmUiPk15IHVzZSBjYXNlcyBhcmUgYSBiaXQgYXR5cGljYWwgZnJvbSB0aGUgd2Vi IHNlcnZpY2UgZHJpdmVuIG1vZGVscyB0aGF0IHlvdSBndXlzIGFyZSBzb2x2aW5nLCBidXQgSSB0 aGluayB0aGUgdGVjaG5vbG9neSBzaG91bGQgc3RpbGwgZml0LiZuYnNwOyBUaGUgUlMgdGhhdCBt eSBuYXRpdmUgY2xpZW50IGlzIHRhbGtpbmcNCiB0byBpcyAqPGI+bm90PC9iPiogYSB3ZWIgc2Vy dmljZSAoSSByZWFsaXplIEnigJltIG5vdCBvdXRzaWRlIHRoZSBib3VuZHMgb2YgT0F1dGgtcHJv cGVyIGhlcmUpLiZuYnNwOyBCdXQgaXTigJlzIGVhc3kgZW5vdWdoIGZvciBtZSB0byB1c2UgT0F1 dGggdG8gZ2V0IGFuIGFjY2Vzcy10b2tlbiBhbmQgaW5jbHVkZSB0aGF0IGluIG15IG1lc3NhZ2Ug YmV0d2VlbiBteSBuYXRpdmUgY2xpZW50IGFuZCBteSAobm9uLXdlYiBzZXJ2aWNlKSBSUy4mbmJz cDsgTXkgUlMgY2FuIHN0aWxsDQogaW50cm9zcGVjdCBpdCBhZ2FpbnN0IGFuIE9BdXRoIFNUUy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOm9saXZlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj5UaGVzZSBuYXRpdmUgYXBwcyBJ4oCZbSBzcGVh a2luZyBvZiwgSeKAmW0gYXR0ZW1wdGluZyB0byByZXRyb2ZpdCB3aXRoIE9BdXRoLCBhbmQgdG9k YXkgdGhleSBhbHJlYWR5IGhhdmUgbmF0aXZlIGludGVyZmFjZXMgZm9yIGFjY2VwdGluZyBhIHVz ZXLigJlzIGxvZ29uIGFuZCBjcmVkZW50aWFscyDigKYgdG8gcG9wIGENCiB3ZWIgYnJvd3NlciB3 b3VsZCBub3QgYmUgaW50dWl0aXZlIHRvIG15IGN1c3RvbWVyIGJhc2UuJm5ic3A7IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6b2xp dmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6b2xpdmUiPkkgZG9u4oCZdCBzZWUgYW55IHJlYXNvbiBJIGNhbuKAmXQg aW1wbGVtZW50IHRoaXMgbmF0aXZlIHdpdGhpbiBteSBjbGllbnQsIGp1c3Qgd2FudCB0byBiZSBz dXJlIHNpbmNlIHRoZSBicm93c2VyIHRyaWNrIGlzIHN1Y2ggYSBwcm9taW5lbnQgdHJlbmQsIEkg d2FudCB0byBiZSBzdXJlIHRoYXQgdGhlcmXigJlzIG5vDQogZ290Y2hhIEkgaGF2ZW7igJl0IHRo b3VnaHQgb2YuJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPlR4ITxicj4NCmFk YW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOm9saXZlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IFBhdWwgTWFkc2VuIFttYWlsdG86cGF1bC5tYWRzZW5AZ21haWwuY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAxOSwgMjAxMiA1OjAzIFBNPGJyPg0KPGI+VG86PC9i PiBMZXdpcyBBZGFtLUNBTDAyMjsganJpY2hlckBtaXRyZS5vcmc8YnI+DQo8Yj5DYzo8L2I+IG9h dXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFVzaW5nIE9B dXRoIHRvIGdldCBhIEpXVC9TQU1MIHRva2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VXNpbmcgdGhlIGJyb3dzZXIgYXMgcGFydCBvZiB0aGUgQVMgaW50 ZXJhY3Rpb24gYWxsb3dzIHlvdSB0byBtb3JlIGVhc2lseSBjb2xsZWN0IHRoZSB1c2VycyBjb25z ZW50LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T25jZSB5b3UgZ2V0IHRoZSB0b2tlbnMgYmFzZWQgb24gdGhhdCBjb25zZW50LCBldmVyeXRoaW5n IGlzICdSRVNUZnVsJzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0t IE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBV c2luZyBPQXV0aCB0byBnZXQgYSBKV1QvU0FNTCB0b2tlbjxicj4NCkZyb206IExld2lzIEFkYW0t Q0FMMDIyICZsdDtBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbSZndDs8YnI+DQpUbzog SnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXRyZS5vcmcmZ3Q7PGJyPg0KQ0M6IFJlOiBbT0FV VEgtV0ddIFVzaW5nIE9BdXRoIHRvIGdldCBhIEpXVC9TQU1MIHRva2VuPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6b2xpdmUiPkhpIEp1c3Rpbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpvbGl2ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6b2xp dmUiPlRoZXJlIGlzIG9uZSB0aGluZyBJIGhhdmUgbm90IHVuZGVyc3Rvb2QgYWJvdXQgdGhlIHdo b2xlIGV4dGVybmFsIGJyb3dzZXIgdnMuIGVtYmVkZGVkIGJyb3dzZXIgZ3VpZGFuY2Ug4oCmIGFu ZCB0aGF0IGlzLCB3aHkgaXMgKjxiPmFueTwvYj4qIGJyb3dzZXIgbmVlZGVkPyZuYnNwOw0KIEph dmEgZm9yIGV4YW1wbGUgaGFzIGFuIEhUVFAgbGlicmFyeSwgYW5kIE9BdXRoIGlzIFJFU1RmdWwu Jm5ic3A7IFNvIHdoeSBpcyBpdCBuZWNlc3NhcnkgdG8gcmVxdWlyZSB0aGUgd2ViIGJyb3dzZXIg YXQgYWxsLCB3aGV0aGVyIGV4dGVybmFsIG9yIGVtYmVkZGVkPyZuYnNwOyBXaHkgY2Fu4oCZdCBt eSBuYXRpdmUgY2xpZW50IG1ha2UgUkVTVGZ1bCBBUEkgY2FsbHMgdG8gdGhlIEFTIGFuZCBSUyBu YXRpdmVseT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjpvbGl2ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6b2xpdmUiPlR4ITwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y Om9saXZlIj5hZGFtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6b2xpdmUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gUmljaGVyIFttYWlsdG86anJpY2hlckBtaXRyZS5v cmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAxMywgMjAxMiAxMTozOCBBTTxi cj4NCjxiPlRvOjwvYj4gTGV3aXMgQWRhbS1DQUwwMjI8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFVzaW5nIE9BdXRoIHRv IGdldCBhIEpXVC9TQU1MIHRva2VuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPklmIHRoZSBtb2JpbGUgZGV2aWNlIGhhcyBhIHdlYiBicm93c2VyIChz dWNoIGFzIGEgc21hcnQgcGhvbmUpLCB0aGVuIHRoaXMgaXMgcHJldHR5IGVhc3ksIGFuZCB5b3Un dmUgZ290IGEgY291cGxlIG9mIG9wdGlvbnMuPGJyPg0KPGJyPg0KT25lIG9mIHRoZSBiZXN0IG9w dGlvbnMgd2hlbiB0aGUgdG9rZW4gaXMgb24gYmVoYWxmIG9mIGFuIGVuZCB1c2VyIGlzLCBpbiBt eSBvcGluaW9uLCB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBmbG93IGxpa2UgdGhpczog Rmlyc3QsIHJlZ2lzdGVyIHdoYXQncyBjYWxsZWQgYSAmcXVvdDtwdWJsaWMgY2xpZW50JnF1b3Q7 IHdpdGggeW91ciBzZXJ2ZXIgLS0gc28geW91J2xsIGdldCBhbiBJRCBidXQgbm90IGEgY2xpZW50 IHNlY3JldC4gV2l0aCB0aGF0IGNsaWVudA0KIElELCByZWdpc3RlciBhIGN1c3RvbS1zY2hlbWUg Y2FsbGJhY2sgVVJJLCBsaWtlICZxdW90O215YXBwOi8vb2F1dGhjYWxsYmFjayZxdW90OywgYW5k IHJlZ2lzdGVyIHlvdXIgYXBwIG9uIHRoZSBkZXZpY2UgYXMgdGhlIGhhbmRsZXIgZm9yICZxdW90 O215YXBwJnF1b3Q7Lg0KPGJyPg0KPGJyPg0KSW4geW91ciBhcHBsaWNhdGlvbiwgdG8gc3RhcnQg dGhpbmdzIG9mZiwgeW91IGZpcmUgb2ZmIGEgd2ViIGJyb3dzZXIgdG8gdGhlIGF1dGhvcml6YXRp b24gc2VydmVyJ3MgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gVGhlIHVzZXIgbG9ncyBpbiB0byB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdGhyb3VnaCB0aGUgd2ViIGJyb3dzZXIsIGFwcHJvdmVz IHRoaXMgY29weSBvZiB5b3VyIGFwcCwgYW5kIGdldHMgcmVkaXJlY3RlZCB0byAmcXVvdDtteWFw cDovL29hdXRoY2FsbGJhY2s/Y29kZT1iYXNkZjEzMiZxdW90Oy4NCiBZb3VyIGFwcCBncmFicyB0 aGUgJnF1b3Q7bXlhcHA6Ly8mcXVvdDsgdXJsIGFuZCBwbHVja3MgdGhlIGF1dGhvcml6YXRpb24g Y29kZSBvZmYgdGhlIGVuZCBvZiBpdC4gWW91ciBhcHAgdGhlbiB0YWtlcyB0aGF0IGNvZGUgYW5k IHNlbmRzIGl0IGluIHRoZSBiYWNrZ3JvdW5kIHRvIHRoZSB0b2tlbiBlbmRwb2ludCB0byBleGNo YW5nZSBmb3IgYSB0b2tlbi4NCjxicj4NCjxicj4NClNvbWUga2V5IHBvaW50czogPGJyPg0KPGJy Pg0KMSkgWW91IG5lZWQgdG8gaGF2ZSBhY2Nlc3MgdG8gYSB3ZWIgYnJvd3NlciBvbiB0aGUgcGxh dGZvcm0sIGFuZCBpdCdzIGNvbnNpZGVyZWQgYmVzdCBwcmFjdGljZSB0byBwdXNoIHRoZSB1c2Vy IHRvIHRoZSBleHRlcm5hbCBicm93c2VyIGFwcGxpY2F0aW9uIG9uIHRoZSBwbGF0Zm9ybSBpbnN0 ZWFkIG9mIGVtYmVkZGluZyBvbmUuIFRoZXJlIGFyZSBhIGNvdXBsZSBwYXJhZ3JhcGhzIGluIHRo ZSBzcGVjJ3Mgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCiBzZWN0aW9uIHRoYXQgdGFsayBhYm91 dCB0aGlzLjxicj4NCjIpIFlvdXIgYXBwIGlzICZxdW90O3B1YmxpYyZxdW90OyBiZWNhdXNlIHlv dSBjYW4ndCBwdWJsaXNoIGl0IHdpdGggYSBzZWNyZXQgYXQgY29uZmlndXJhdGlvbiB0aW1lLiBJ dCBjYW4sIGhvd2V2ZXIsIGtlZXAgdGhlIHRva2VucyBzZWNyZXQgYXQgcnVudGltZS48YnI+DQoz KSBZb3UgbmVlZCB0byBiZSB2ZXJ5IGNhcmVmdWwgd2l0aCBob3cgeW91IHN0b3JlIHRoZSB0b2tl bnMgb24gdGhlIGRldmljZSAtLSB0aGV5IG5lZWQgdG8gYmUgaW4gYSB0cnVzdGVkIHNwYWNlIHdo ZXJlIG90aGVyIGFwcHMgb24gdGhlIGRldmljZSBjYW4ndCBzbmlmZiB0aGVtIG91dC48YnI+DQo0 KSBBbm90aGVyIGFwcCBjYW4gdHJ5IHRvIHJlZ2lzdGVyICZxdW90O215YXBwOi8vJnF1b3Q7IGFu ZCBpbnRlcmNlcHQgeW91ciBjb2RlIG9uIHRoZSB3YXkgdGhyb3VnaCwgc28gbWFrZSBzdXJlIHlv dXIgY29kZXMgYXJlIGFsbCBvbmUgdGltZSB1c2UgYW5kIHNob3J0IGxpdmVkLjxicj4NCjxicj4N Ck5vbmUgb2YgdGhpcyBpcyBqdXN0IHRoZW9yZXRpY2FsbHkgcG9zc2libGUsIHBlb3BsZSBhcmUg ZG9pbmcgaXQgdG9kYXkuIFdoYXQgbGlicmFyaWVzIGFuZCBzdHVmZiB5b3UnZCBiZSBhZnRlciBk ZXBlbmRzIHdob2xseSBvbiB5b3VyIHBsYXRmb3JtIChib3RoIHNlcnZlciBhbmQgY2xpZW50IHNp ZGUpLg0KPGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPGJyPg0KPGJyPg0KT24gMDQvMTIvMjAx MiAwMzowMSBQTSwgTGV3aXMgQWRhbS1DQUwwMjIgd3JvdGU6IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J 4oCZdmUgYmVlbiB0YWxraW5nIHRvIHNvbWUgb2YgeW91IG9mZiBsaW5lIGFib3V0IHRoaXMgYWxy ZWFkeSwgYnV0IEkgbmVlZCBzb21lIGhlbHAgaW4gdGVybXMgb2YgaW1wbGVtZW50YXRpb24uJm5i c3A7IEkgd291bGQgbGlrZSB0byB1c2UgT0F1dGggYXMgYSBtZWFucyB0byBnZXQgZWl0aGVyIGEg SldUIG9yIFNBTUwNCiB0b2tlbiB0byBhIGNsaWVudCBydW5uaW5nIG9uIGEgaGFuZGhlbGQgZGV2 aWNlLiZuYnNwOyBUaGlzIGlzIHNvbWV0aGluZyB0aGF0IEnigJltIGxvb2tpbmcgdG8gcHJvdG90 eXBlIChhcyBwYXJ0IG9mIGEgbGFyZ2VyIHByb2plY3QpIGJlZ2lubmluZyB0aGlzIHdlZWsuJm5i c3A7IFNvLCBpdCBpcyBpbXBvcnRhbnQgdG8gbWUgdG8gdW5kZXJzdGFuZCB0aGUgZGl2aWRlIGJl dHdlZW4gd2hhdCBpcyB0aGVvcmV0aWNhbGx5IHBvc3NpYmxlIGFuZCB3aGF0IGlzIGFjdHVhbGx5 DQogcG9zc2libGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Bbnlib2R5IGF3YXJlIG9m IGFueSBpbXBsZW1lbnRhdGlvbnMgb3V0IHRoZXJlLCBlaXRoZXIgdmVuZG9yIG9yIG9wZW4gc291 cmNlLCB0aGF0IEkgY2FuIHVzZSBmb3IgdGhpcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlR4ITxicj4NCmFkYW08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+ T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_59E470B10C4630419ED717AC79FCF9A9097843BL2PRD0410MB363na_-- From Adam.Lewis@motorolasolutions.com Thu Apr 19 15:25:50 2012 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 2C6CC21F8526 for ; Thu, 19 Apr 2012 15:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYQz+aiZWAeQ for ; Thu, 19 Apr 2012 15:25:47 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 87C2E21F850C for ; Thu, 19 Apr 2012 15:25:46 -0700 (PDT) Received: from mail5-am1-R.bigfish.com (10.3.201.238) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 22:25:45 +0000 Received: from mail5-am1 (localhost [127.0.0.1]) by mail5-am1-R.bigfish.com (Postfix) with ESMTP id 7307C3201FD for ; Thu, 19 Apr 2012 22:25:45 +0000 (UTC) X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI9371Ic85fh98dK14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25h) X-Forefront-Antispam-Report: CIP:192.160.210.20; KIP:(null); UIP:(null); IPV:NLI; H:il27msg01.am.mot-solutions.com; RD:il27msg01.mot-solutions.com; EFVD:NLI Received-SPF: pass (mail5-am1: domain of motorolasolutions.com designates 192.160.210.20 as permitted sender) client-ip=192.160.210.20; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il27msg01.am.mot-solutions.com ; olutions.com ; Received: from mail5-am1 (localhost.localdomain [127.0.0.1]) by mail5-am1 (MessageSwitch) id 1334874343894835_14087; Thu, 19 Apr 2012 22:25:43 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.234]) by mail5-am1.bigfish.com (Postfix) with ESMTP id D49EF120057 for ; Thu, 19 Apr 2012 22:25:43 +0000 (UTC) Received: from il27msg01.am.mot-solutions.com (192.160.210.20) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 22:25:43 +0000 Received: from il27msg01.am.mot-solutions.com (ct11vts02.am.mot.com [10.177.16.160]) by il27msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3JMbQUV028814 for ; Thu, 19 Apr 2012 17:37:27 -0500 (CDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by il27msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q3JMbP6A028805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 19 Apr 2012 17:37:26 -0500 (CDT) Received: from mail75-db3-R.bigfish.com (10.3.81.243) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 22:25:38 +0000 Received: from mail75-db3 (localhost [127.0.0.1]) by mail75-db3-R.bigfish.com (Postfix) with ESMTP id 5593D1E0722 for ; Thu, 19 Apr 2012 22:25:38 +0000 (UTC) Received: from mail75-db3 (localhost.localdomain [127.0.0.1]) by mail75-db3 (MessageSwitch) id 1334874336201175_32368; Thu, 19 Apr 2012 22:25:36 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.246]) by mail75-db3.bigfish.com (Postfix) with ESMTP id 2CDFEA0479; Thu, 19 Apr 2012 22:25:36 +0000 (UTC) Received: from BL2PRD0410HT003.namprd04.prod.outlook.com (157.56.240.85) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 22:25:35 +0000 Received: from BL2PRD0410MB363.namprd04.prod.outlook.com ([169.254.3.84]) by BL2PRD0410HT003.namprd04.prod.outlook.com ([10.255.99.38]) with mapi id 14.16.0143.004; Thu, 19 Apr 2012 22:25:35 +0000 From: Lewis Adam-CAL022 To: Brian Campbell Thread-Topic: [OAUTH-WG] Using OAuth to get a JWT/SAML token Thread-Index: AQHNHnkKVdHTUrYT/0+qOjOa2wdFq5aiuSuw Date: Thu, 19 Apr 2012 22:25:34 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A909785B@BL2PRD0410MB363.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A906E74E@CH1PRD0410MB369.namprd04.prod.outlook.com> <4F885680.5090801@mitre.org> <59E470B10C4630419ED717AC79FCF9A9090519@CH1PRD0410MB369.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.9.149] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A909785BBL2PRD0410MB363na_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0410HT003.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False;00160000;True;; X-OrganizationHeadersPreserved: BL2PRD0410HT003.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%PINGIDENTITY.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MITRE.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Thu, 19 Apr 2012 22:25:50 -0000 --_000_59E470B10C4630419ED717AC79FCF9A909785BBL2PRD0410MB363na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, I was also looking at the resource owner credentials flow, but it seems lim= ited to username & password ... it's not clear that it would work with stro= nger authentication methods such as RSA. Thoughts? adam From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Thursday, April 19, 2012 5:08 PM To: Lewis Adam-CAL022 Cc: Justin Richer; oauth@ietf.org Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token A browser isn't required. The browser based flows are pretty common with OA= uth but they are certainly not the only way to get a token. The resource owner credentials and client credentials grant types are both = involve only direct communication between the client and the AS. And there = are also the SAML and JWT grants that allow a client to get an access token= directly from an AS without a browser being involved. On Thu, Apr 19, 2012 at 3:37 PM, Lewis Adam-CAL022 > wrote: Hi Justin, There is one thing I have not understood about the whole external browser v= s. embedded browser guidance ... and that is, why is *any* browser needed? = Java for example has an HTTP library, and OAuth is RESTful. So why is it = necessary to require the web browser at all, whether external or embedded? = Why can't my native client make RESTful API calls to the AS and RS nativel= y? Tx! adam From: Justin Richer [mailto:jricher@mitre.org] Sent: Friday, April 13, 2012 11:38 AM To: Lewis Adam-CAL022 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token If the mobile device has a web browser (such as a smart phone), then this i= s pretty easy, and you've got a couple of options. One of the best options when the token is on behalf of an end user is, in m= y opinion, to use the authorization code flow like this: First, register wh= at's called a "public client" with your server -- so you'll get an ID but n= ot a client secret. With that client ID, register a custom-scheme callback = URI, like "myapp://oauthcallback", and register your app on the device as t= he handler for "myapp". In your application, to start things off, you fire off a web browser to the= authorization server's authorization endpoint. The user logs in to the aut= horization server through the web browser, approves this copy of your app, = and gets redirected to "myapp://oauthcallback?code=3Dbasdf132". Your app gr= abs the "myapp://" url and plucks the authorization code off the end of it.= Your app then takes that code and sends it in the background to the token = endpoint to exchange for a token. Some key points: 1) You need to have access to a web browser on the platform, and it's consi= dered best practice to push the user to the external browser application on= the platform instead of embedding one. There are a couple paragraphs in th= e spec's security considerations section that talk about this. 2) Your app is "public" because you can't publish it with a secret at confi= guration time. It can, however, keep the tokens secret at runtime. 3) You need to be very careful with how you store the tokens on the device = -- they need to be in a trusted space where other apps on the device can't = sniff them out. 4) Another app can try to register "myapp://" and intercept your code on th= e way through, so make sure your codes are all one time use and short lived= . None of this is just theoretically possible, people are doing it today. Wha= t libraries and stuff you'd be after depends wholly on your platform (both = server and client side). -- Justin On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote: Hi all, I've been talking to some of you off line about this already, but I need so= me help in terms of implementation. I would like to use OAuth as a means t= o get either a JWT or SAML token to a client running on a handheld device. = This is something that I'm looking to prototype (as part of a larger proje= ct) beginning this week. So, it is important to me to understand the divid= e between what is theoretically possible and what is actually possible. Anybody aware of any implementations out there, either vendor or open sourc= e, that I can use for this? Tx! adam _______________________________________________ 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 --_000_59E470B10C4630419ED717AC79FCF9A909785BBL2PRD0410MB363na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian,

 

I was also looking at the resource owner cre= dentials flow, but it seems limited to username & password … it&#= 8217;s not clear that it would work with stronger authentication methods such as RSA.  Thoughts?

 

adam

 

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, April 19, 2012 5:08 PM
To: Lewis Adam-CAL022
Cc: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

 

A browser isn't requi= red. The browser based flows are pretty common with OAuth but they are cert= ainly not the only way to get a token.

The resource owner credentials and client credentials grant types are both = involve only direct communication between the client and the AS. And there = are also the SAML and JWT grants that allow a client to get an access token= directly from an AS without a browser being involved.

On Thu, Apr 19, 2012 at 3:37 PM, Lewis Adam-CAL022 &= lt;Adam.Lewis@motorolas= olutions.com> wrote:

Hi Justin,

 

There is one thing I have not understo= od about the whole external browser vs. embedded browser guidance … a= nd that is, why is *any* browser needed?  Java for example has an HTTP library, and OAuth is RESTful.  So why i= s it necessary to require the web browser at all, whether external or embed= ded?  Why can’t my native client make RESTful API calls to the A= S and RS natively?

 

Tx!

adam

 

From: Justin Richer [mailto:= jricher@mitre.org]
Sent: Friday, April 13, 2012 11:38 AM
To: Lewis Adam-CAL022
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

 

If the mobile device has a web browser (such as a smart phone), th= en this is pretty easy, and you've got a couple of options.

One of the best options when the token is on behalf of an end user is, in m= y opinion, to use the authorization code flow like this: First, register wh= at's called a "public client" with your server -- so you'll get a= n ID but not a client secret. With that client ID, register a custom-scheme callback URI, like "myapp://oauthcallbac= k", and register your app on the device as the handler for "myapp= ".

In your application, to start things off, you fire off a web browser to the= authorization server's authorization endpoint. The user logs in to the aut= horization server through the web browser, approves this copy of your app, = and gets redirected to "myapp://oauthcallback?code=3Dbasdf132". Your app grabs the "myapp://" url and plucks the authorization c= ode off the end of it. Your app then takes that code and sends it in the ba= ckground to the token endpoint to exchange for a token.

Some key points:

1) You need to have access to a web browser on the platform, and it's consi= dered best practice to push the user to the external browser application on= the platform instead of embedding one. There are a couple paragraphs in th= e spec's security considerations section that talk about this.
2) Your app is "public" because you can't publish it with a secre= t at configuration time. It can, however, keep the tokens secret at runtime= .
3) You need to be very careful with how you store the tokens on the device = -- they need to be in a trusted space where other apps on the device can't = sniff them out.
4) Another app can try to register "myapp://" and intercept your = code on the way through, so make sure your codes are all one time use and s= hort lived.

None of this is just theoretically possible, people are doing it today. Wha= t libraries and stuff you'd be after depends wholly on your platform (both = server and client side).

 -- Justin

On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote:

Hi all,

 

I’ve been talking to some of you off line about this already= , but I need some help in terms of implementation.  I would like to us= e OAuth as a means to get either a JWT or SAML token to a client running on a handheld device.  This is something th= at I’m looking to prototype (as part of a larger project) beginning t= his week.  So, it is important to me to understand the divide between = what is theoretically possible and what is actually possible.

 

Anybody aware of any implementations out there, either vendor or o= pen source, that I can use for this?

 

Tx!
adam



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 

--_000_59E470B10C4630419ED717AC79FCF9A909785BBL2PRD0410MB363na_-- From ve7jtb@ve7jtb.com Thu Apr 19 15:35:46 2012 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 53CDE21F8568 for ; Thu, 19 Apr 2012 15:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtvxM3jo917i for ; Thu, 19 Apr 2012 15:35:45 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B66B921F8567 for ; Thu, 19 Apr 2012 15:35:44 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so6155336wgb.13 for ; Thu, 19 Apr 2012 15:35:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=/9cFKwE8uGjWnTehG2eT0UoLBErxSPrXmh7HAyh/IwI=; b=Z1oDPiXZEcO26NBTH13ZDSGlZ1w9Xfoi5/8AgWkTBCtJefQLWsKvOu5OnAtp/wFNlx L0sHdYxGtRRM/c1RIzuOj3GgP/Mz0h0Fumr6AUhiwLgl8GFY3fMkOIKOVgnO7TIL6cd/ gWzFa7eB06XCmXIBJRoKfwAUkKEW+a+iyzt9cUt0GuonaUwBOGdZvo36ckxDN4J1lzl7 6riwwDDqXMZX7Ch0gunvk1cSZMJyuX02dAVEIH74uTRWccLYRvUmGRdMC6wJKd9nMIux tL3PzDUl2SoZQii9czd33mQ6MxRmo+VOws+P7ZC2J5e8YCfeuMDY0Et5Zt9wZ6UlNCgz 4e1A== Received: by 10.180.102.100 with SMTP id fn4mr9389671wib.1.1334874943625; Thu, 19 Apr 2012 15:35:43 -0700 (PDT) Received: from [10.0.9.253] ([212.144.56.68]) by mx.google.com with ESMTPS id o2sm1368963wiv.11.2012.04.19.15.35.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 15:35:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_A5B2597C-970F-4DEA-8277-D1EE63711498"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9097843@BL2PRD0410MB363.namprd04.prod.outlook.com> Date: Fri, 20 Apr 2012 00:35:37 +0200 Message-Id: References: <5jrlua1y80mdxtvpmygf5tp1.1334872982862@email.android.com> <59E470B10C4630419ED717AC79FCF9A9097843@BL2PRD0410MB363.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnjWGcwz3EUgxVgb0/qofsqv+7WJUi2pQkAglalTQGQtq9Fm5JgeR1TpxMui0ssaF+HKG5h Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Thu, 19 Apr 2012 22:35:46 -0000 --Apple-Mail=_A5B2597C-970F-4DEA-8277-D1EE63711498 Content-Type: multipart/alternative; boundary="Apple-Mail=_42216F9E-7054-48B8-81FE-D8D541FF93AC" --Apple-Mail=_42216F9E-7054-48B8-81FE-D8D541FF93AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The goal is to train users to use a trusted browser to enter credentials = rather than an embedded app that is phishing there authentication = credentials. The other advantage is that if there are multiple apps the browser can = maintain session state across provisioning tokens for multiple apps with = a single login. Can the app embed a browser? YEs it is easy, but it trains the user to = do the wrong thing with untreated apps. John B. On 2012-04-20, at 12:11 AM, Lewis Adam-CAL022 wrote: > Hi Paul, > =20 > So by saying =91more easily=92 then there is nothing really inherently = preventing a native implementation from making the HTTP calls to the AS = directly, right? > =20 > My use cases are a bit atypical from the web service driven models = that you guys are solving, but I think the technology should still fit. = The RS that my native client is talking to is *not* a web service (I = realize I=92m not outside the bounds of OAuth-proper here). But it=92s = easy enough for me to use OAuth to get an access-token and include that = in my message between my native client and my (non-web service) RS. My = RS can still introspect it against an OAuth STS. > =20 > These native apps I=92m speaking of, I=92m attempting to retrofit with = OAuth, and today they already have native interfaces for accepting a = user=92s logon and credentials =85 to pop a web browser would not be = intuitive to my customer base.=20 > =20 > I don=92t see any reason I can=92t implement this native within my = client, just want to be sure since the browser trick is such a prominent = trend, I want to be sure that there=92s no gotcha I haven=92t thought = of.=20 > =20 > Tx! > adam > =20 > From: Paul Madsen [mailto:paul.madsen@gmail.com]=20 > Sent: Thursday, April 19, 2012 5:03 PM > To: Lewis Adam-CAL022; jricher@mitre.org > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token > =20 > Using the browser as part of the AS interaction allows you to more = easily collect the users consent.=20 > =20 > Once you get the tokens based on that consent, everything is 'RESTful' >=20 >=20 >=20 > -------- Original message -------- > Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token > From: Lewis Adam-CAL022 > To: Justin Richer > CC: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token >=20 >=20 > Hi Justin, > =20 > There is one thing I have not understood about the whole external = browser vs. embedded browser guidance =85 and that is, why is *any* = browser needed? Java for example has an HTTP library, and OAuth is = RESTful. So why is it necessary to require the web browser at all, = whether external or embedded? Why can=92t my native client make RESTful = API calls to the AS and RS natively? > =20 > Tx! > adam > =20 > From: Justin Richer [mailto:jricher@mitre.org]=20 > Sent: Friday, April 13, 2012 11:38 AM > To: Lewis Adam-CAL022 > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token > =20 > If the mobile device has a web browser (such as a smart phone), then = this is pretty easy, and you've got a couple of options. >=20 > One of the best options when the token is on behalf of an end user is, = in my opinion, to use the authorization code flow like this: First, = register what's called a "public client" with your server -- so you'll = get an ID but not a client secret. With that client ID, register a = custom-scheme callback URI, like "myapp://oauthcallback", and register = your app on the device as the handler for "myapp".=20 >=20 > In your application, to start things off, you fire off a web browser = to the authorization server's authorization endpoint. The user logs in = to the authorization server through the web browser, approves this copy = of your app, and gets redirected to = "myapp://oauthcallback?code=3Dbasdf132". Your app grabs the "myapp://" = url and plucks the authorization code off the end of it. Your app then = takes that code and sends it in the background to the token endpoint to = exchange for a token.=20 >=20 > Some key points:=20 >=20 > 1) You need to have access to a web browser on the platform, and it's = considered best practice to push the user to the external browser = application on the platform instead of embedding one. There are a couple = paragraphs in the spec's security considerations section that talk about = this. > 2) Your app is "public" because you can't publish it with a secret at = configuration time. It can, however, keep the tokens secret at runtime. > 3) You need to be very careful with how you store the tokens on the = device -- they need to be in a trusted space where other apps on the = device can't sniff them out. > 4) Another app can try to register "myapp://" and intercept your code = on the way through, so make sure your codes are all one time use and = short lived. >=20 > None of this is just theoretically possible, people are doing it = today. What libraries and stuff you'd be after depends wholly on your = platform (both server and client side).=20 >=20 > -- Justin >=20 > On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote: > Hi all, > =20 > I=92ve been talking to some of you off line about this already, but I = need some help in terms of implementation. I would like to use OAuth as = a means to get either a JWT or SAML token to a client running on a = handheld device. This is something that I=92m looking to prototype (as = part of a larger project) beginning this week. So, it is important to = me to understand the divide between what is theoretically possible and = what is actually possible. > =20 > Anybody aware of any implementations out there, either vendor or open = source, that I can use for this? > =20 > Tx! > adam >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_42216F9E-7054-48B8-81FE-D8D541FF93AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The goal is to train users to use a trusted browser = to enter credentials rather than an embedded app that is phishing there = authentication credentials.

The other advantage is = that if there are multiple apps the browser can maintain session state = across provisioning tokens for multiple apps with a single = login.

Can the app embed a browser?  YEs = it is easy, but it trains the user to do the wrong thing with untreated = apps.

John B.
On 2012-04-20, at = 12:11 AM, Lewis Adam-CAL022 wrote:

Hi = Paul,
 
So by saying =91more easily=92 then there is nothing really = inherently preventing a native implementation from making the HTTP calls = to the AS directly, right?
 
My use cases are a bit atypical = from the web service driven models that you guys are solving, but I = think the technology should still fit.  The RS that my native = client is talking to is *not* a web service (I realize I=92m not = outside the bounds of OAuth-proper here).  But it=92s easy enough = for me to use OAuth to get an access-token and include that in my = message between my native client and my (non-web service) RS.  My = RS can still introspect it against an OAuth = STS.
 
These native apps I=92m speaking of, I=92m attempting to = retrofit with OAuth, and today they already have native interfaces for = accepting a user=92s logon and credentials =85 to pop a web browser = would not be intuitive to my customer = base. 
 
I don=92t see any reason I can=92t implement this native within = my client, just want to be sure since the browser trick is such a = prominent trend, I want to be sure that there=92s no gotcha I haven=92t = thought of. 
 
Tx!
adam
From: Paul Madsen = [mailto:paul.madsen@gmail.com] 
Sent: Thursday, April 19, 2012 = 5:03 PM
To: Lewis Adam-CAL022; jricher@mitre.org
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using OAuth = to get a JWT/SAML token
 
Using the browser as part = of the AS interaction allows you to more easily collect the users = consent. 
Once you get the tokens = based on that consent, everything is 'RESTful'




-------- Original message = --------
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML = token
From: Lewis Adam-CAL022 <Adam.Lewis@motorolasoluti= ons.com>
To: Justin Richer <jricher@mitre.org>
CC: Re: = [OAUTH-WG] Using OAuth to get a JWT/SAML = token

Hi Justin,
 
There is one thing I = have not understood about the whole external browser vs. embedded = browser guidance =85 and that is, why is *any* browser = needed?  Java for example has an HTTP library, and OAuth is = RESTful.  So why is it necessary to require the web browser at all, = whether external or embedded?  Why can=92t my native client make = RESTful API calls to the AS and RS natively?
Tx!
adam
 
 Justin = Richer [mailto:jricher@mitre.org] 
Sent: Friday, April 13, 2012 = 11:38 AM
To: Lewis = Adam-CAL022
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using OAuth = to get a JWT/SAML token
 
If the mobile device has = a web browser (such as a smart phone), then this is pretty easy, and = you've got a couple of options.

One of the best options when the = token is on behalf of an end user is, in my opinion, to use the = authorization code flow like this: First, register what's called a = "public client" with your server -- so you'll get an ID but not a client = secret. With that client ID, register a custom-scheme callback URI, like = "myapp://oauthcallback", and = register your app on the device as the handler for "myapp". 

In your = application, to start things off, you fire off a web browser to the = authorization server's authorization endpoint. The user logs in to the = authorization server through the web browser, approves this copy of your = app, and gets redirected to "myapp://oauthcallback?code=3D= basdf132". Your app grabs the "myapp://" url and plucks the = authorization code off the end of it. Your app then takes that code and = sends it in the background to the token endpoint to exchange for a = token. 

Some = key points: 

1) = You need to have access to a web browser on the platform, and it's = considered best practice to push the user to the external browser = application on the platform instead of embedding one. There are a couple = paragraphs in the spec's security considerations section that talk about = this.
2) Your app is "public" because you can't publish it with a = secret at configuration time. It can, however, keep the tokens secret at = runtime.
3) You need to be very careful with how you store the tokens = on the device -- they need to be in a trusted space where other apps on = the device can't sniff them out.
4) Another app can try to register = "myapp://" and intercept your code on the way through, so make sure your = codes are all one time use and short lived.

None of this is just = theoretically possible, people are doing it today. What libraries and = stuff you'd be after depends wholly on your platform (both server and = client side). 

 -- = Justin

On 04/12/2012 03:01 PM, Lewis Adam-CAL022 = wrote:
Hi all,
 
I=92ve been talking to = some of you off line about this already, but I need some help in terms = of implementation.  I would like to use OAuth as a means to get = either a JWT or SAML token to a client running on a handheld = device.  This is something that I=92m looking to prototype (as part = of a larger project) beginning this week.  So, it is important to = me to understand the divide between what is theoretically possible and = what is actually possible.
Anybody aware of any = implementations out there, either vendor or open source, that I can use = for this?
 
Tx!
adam
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_42216F9E-7054-48B8-81FE-D8D541FF93AC-- --Apple-Mail=_A5B2597C-970F-4DEA-8277-D1EE63711498 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQx OTIyMzUzN1owIwYJKoZIhvcNAQkEMRYEFHSmlWpuEUINW6ZGMx3ItXPF7/a2MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AIZXle4+sBgClgf5lIGwVfCWjw8YI0pgrObjMwF0PCsQ03gu9EjVTy6iRWBpkYsoR/C0gR2ti39r fps0SnKD9T8ZpjgbO38YSAV5TA3t6n93ozmNiQSUQ5HInINIsghqVzhqHSWMyjWe5P7AV/Lv+8hr Ca2fREDg+2VVtqZzBoUU5+9BbTb8QrUboe18DeW900NZPm8GtYseq8oiiP5om2hB7o+SqBowzMld Ak4vqaz2dXaemske37E6ezx0cAV6Ff/miPQTtrBYwhTMXzJnrJwJQ5AXaWSLj5SeAUVRkogEJuni 0Jwa21AjkWxd28HJWFDPbMkdxUWXVjWk3cOHcZcAAAAAAAA= --Apple-Mail=_A5B2597C-970F-4DEA-8277-D1EE63711498-- From wmills@yahoo-inc.com Thu Apr 19 16:21:14 2012 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 7FFD021F85D0 for ; Thu, 19 Apr 2012 16:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.27 X-Spam-Level: X-Spam-Status: No, score=-17.27 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk50lwD-r53n for ; Thu, 19 Apr 2012 16:21:13 -0700 (PDT) Received: from nm17.bullet.mail.bf1.yahoo.com (nm17.bullet.mail.bf1.yahoo.com [98.139.212.176]) by ietfa.amsl.com (Postfix) with SMTP id C429221F85C4 for ; Thu, 19 Apr 2012 16:21:12 -0700 (PDT) Received: from [98.139.214.32] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 19 Apr 2012 23:21:11 -0000 Received: from [98.139.212.244] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 19 Apr 2012 23:21:11 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 19 Apr 2012 23:21:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 935252.93862.bm@omp1053.mail.bf1.yahoo.com Received: (qmail 65013 invoked by uid 60001); 19 Apr 2012 23:21:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334877671; bh=5CXMzbnd5/k2/nZktRKe4x2G82/C/Rs4yd7R1WDBU48=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=oGix/TH0lgvLOL7CPod3aj2I9uFujorX3n9/VqweTGtVaa6fUzwShG3m08V9d8b6HRrc0GuPB8CFIXu5vYM3xgkfFHkLoH3C12lubNoCEqzGsgC1P2qXaWZXZXsQTgv5eSIyUcTP7WvnWEfQNRLU4fCNe4Q2Oba8Fe5eaxqqL7o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XwS0g1qSz8JXkD5WIY3IjX1Y63/hjxssg5owt+lW93CVB5dxs8aOKRk5jr1LSjWe1w3V+dtmbL0jMuuIfemm8kjAq52Xqk9/lmBjVsd2Gcb2iaCvPSP7A591If2LjRTmugFmO2C16dyT6mRfP/2XeC0vVTfnp4TgwljiB+6x4Ho=; X-YMail-OSG: HPoCs.MVM1nHpWJbUJCkQT8KIt3PLTaeJsdZCuYKKqgRR.U NTC51Q4uDtdKU03Kj1tEwKxHdjU19iuOdzxlsUJ0X.sKArKMGTzYuSTYOwiN 3nAP6REgBFpTlQCm7h.L4TaJADmox1rb7rdxpLigtN8PQv8d1_LXD9mbji4z MmCdS9Ib8585wqaDpuZeEnTuyVHQ5I4filJHwn7mfXlQMGyeo_5Xd7VovDaJ FVAAQP69hQbo1UoHZ0_e7MKXmYGScn.Szoi94Zurd7hKLpL2LTPPG2qaQRGa aYANO_ibKALhF_cEfAM08QnxR2g0pX0fdNpGEqR96G7kEJoMDkZ0ylRs7pDP QywqDyMRSXVh8u_2Xif8qyX0z4pkSlm4W_FcLwFECQiTMPlYc.pUJDQ1RusW Mp0DA06e4flMA6lPwDopJgVOFxvoVaCuwQV_Q0hWp7lhfOG_9Rtkyfw-- Received: from [209.131.62.120] by web31802.mail.mud.yahoo.com via HTTP; Thu, 19 Apr 2012 16:21:10 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <5jrlua1y80mdxtvpmygf5tp1.1334872982862@email.android.com> Message-ID: <1334877670.64827.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 19 Apr 2012 16:21:10 -0700 (PDT) From: William Mills To: Paul Madsen , "adam.lewis@motorolasolutions.com" , "jricher@mitre.org" In-Reply-To: <5jrlua1y80mdxtvpmygf5tp1.1334872982862@email.android.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-64407182-1334877670=:64827" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 23:21:14 -0000 ---1036955950-64407182-1334877670=:64827 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Various additional anti-abuse controls can be applied like CAPTCHA if you h= ave a full browser to leverage.=C2=A0 Much harder to get that flexibility i= n a fixed client UI.=C2=A0 =0A=0A=0A=0A=0A>________________________________= =0A> From: Paul Madsen =0A>To: adam.lewis@motorolaso= lutions.com; jricher@mitre.org =0A>Cc: oauth@ietf.org =0A>Sent: Thursday, A= pril 19, 2012 3:03 PM=0A>Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/S= AML token=0A> =0A>=0A>Using the browser as part of the AS interaction allow= s you to more easily collect the users consent.=C2=A0=0A>=0A>=0A>Once you g= et the tokens based on that consent, everything is 'RESTful'=0A>=0A>=0A>---= ----- Original message --------=0A>Subject: Re: [OAUTH-WG] Using OAuth to g= et a JWT/SAML token=0A>From: Lewis Adam-CAL022 =0A>To: Justin Richer =0A>CC: Re: [OAUTH-WG] Using= OAuth to get a JWT/SAML token=0A>=0A>=0A>=0A>Hi Justin,=0A>=C2=A0=0A>There= is one thing I have not understood about the whole external browser vs. em= bedded browser guidance =E2=80=A6 and that is, why is *any* browser needed?= =C2=A0 Java for example has an HTTP library, and OAuth is RESTful.=C2=A0 So= why is it necessary to require the web browser at all, whether external or= embedded?=C2=A0 Why can=E2=80=99t my native client make RESTful API calls = to the AS and RS natively?=0A>=C2=A0=0A>Tx!=0A>adam=0A>=C2=A0=0A>From:Justi= n Richer [mailto:jricher@mitre.org] =0A>Sent: Friday, April 13, 2012 11:38 = AM=0A>To: Lewis Adam-CAL022=0A>Cc: oauth@ietf.org=0A>Subject: Re: [OAUTH-WG= ] Using OAuth to get a JWT/SAML token=0A>=C2=A0=0A>If the mobile device has= a web browser (such as a smart phone), then this is pretty easy, and you'v= e got a couple of options.=0A>=0A>One of the best options when the token is= on behalf of an end user is, in my opinion, to use the authorization code = flow like this: First, register what's called a "public client" with your s= erver -- so you'll get an ID but not a client secret. With that client=0A I= D, register a custom-scheme callback URI, like "myapp://oauthcallback", and= register your app on the device as the handler for "myapp". =0A>=0A>In you= r application, to start things off, you fire off a web browser to the autho= rization server's authorization endpoint. The user logs in to the authoriza= tion server through the web browser, approves this copy of your app, and ge= ts redirected to "myapp://oauthcallback?code=3Dbasdf132".=0A Your app grabs= the "myapp://" url and plucks the authorization code off the end of it. Yo= ur app then takes that code and sends it in the background to the token end= point to exchange for a token. =0A>=0A>Some key points: =0A>=0A>1) You need= to have access to a web browser on the platform, and it's considered best = practice to push the user to the external browser application on the platfo= rm instead of embedding one. There are a couple paragraphs in the spec's se= curity considerations=0A section that talk about this.=0A>2) Your app is "p= ublic" because you can't publish it with a secret at configuration time. It= can, however, keep the tokens secret at runtime.=0A>3) You need to be very= careful with how you store the tokens on the device -- they need to be in = a trusted space where other apps on the device can't sniff them out.=0A>4) = Another app can try to register "myapp://" and intercept your code on the w= ay through, so make sure your codes are all one time use and short lived.= =0A>=0A>None of this is just theoretically possible, people are doing it to= day. What libraries and stuff you'd be after depends wholly on your platfor= m (both server and client side). =0A>=0A>=C2=A0-- Justin=0A>=0A>On 04/12/20= 12 03:01 PM, Lewis Adam-CAL022 wrote: =0A>Hi all,=0A>=C2=A0=0A>I=E2=80=99ve= been talking to some of you off line about this already, but I need some h= elp in terms of implementation.=C2=A0 I would like to use OAuth as a means = to get either a JWT or SAML token to a client running on a handheld device.= =C2=A0 This is something that I=E2=80=99m looking to prototype (as part of = a larger project) beginning this week.=C2=A0 So, it is important to me to u= nderstand the divide between what is theoretically possible and what is act= ually possible.=0A>=C2=A0=0A>Anybody aware of any implementations out there= , either vendor or open source, that I can use for this?=0A>=C2=A0=0A>Tx!= =0A>adam=0A>=0A>=0A>=0A>=0A>_______________________________________________= =0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/li= stinfo/oauth=0A>=C2=A0=0A>_______________________________________________= =0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/li= stinfo/oauth=0A>=0A>=0A> ---1036955950-64407182-1334877670=:64827 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Various additional anti-abuse controls can be applied like CAPTCHA if you= have a full browser to leverage.  Much harder to get that flexibility= in a fixed client UI. 

From: Paul Madsen <paul.madsen@gmail.com> To: adam.lewis@motorola= solutions.com; jricher@mitre.org
= Cc: oauth@ietf.org
Sent:= Thursday, April 19, 2012 3:03 PM
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token
=

=0A
Using the browser as p= art of the AS interaction allows you to more easily collect the users conse= nt. 

Once you get the tokens based on that consent,= everything is 'RESTful'



-------- Original message -------= -
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token
From: L= ewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com>
To: Justin Ric= her <jricher@mitre.org>
CC: Re: [OAUTH-WG] Using OAuth to get a JW= T/SAML token


=0A
= Hi Justin,
=0A
 
=0A
There is= one thing I have not understood about the whole external browser vs. embed= ded browser guidance =E2=80=A6 and that is, why is *any* browser nee= ded?  Java for example has an HTTP library,=0A and OAuth is RESTful.&n= bsp; So why is it necessary to require the web browser at all, whether exte= rnal or embedded?  Why can=E2=80=99t my native client make RESTful API= calls to the AS and RS natively?
=0A
  =0A
Tx!
=0A
adam
=0A
&= nbsp;
=0A
=0A
=0A
From:= Justin Richer [mailto:j= richer@mitre.org]=0A
=0ASent: Friday, April 13, 2012 11:38 AM
= =0ATo: Lewis Adam-CAL022
=0ACc: oauth@ietf.org
=0ASu= bject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token
= =0A
=0A
=0A
 
=0A=
If the mobile device has a web browser= (such as a smart phone), then this is pretty easy, and you've got a couple= of options.
=0A
=0AOne of the best options when the token is on beha= lf of an end user is, in my opinion, to use the authorization code flow lik= e this: First, register what's called a "public client" with your server --= so you'll get an ID but not a client secret. With that client=0A ID, regis= ter a custom-scheme callback URI, like "myapp://oauthcallback", and registe= r your app on the device as the handler for "myapp".=0A
=0A
=0AIn you= r application, to start things off, you fire off a web browser to the autho= rization server's authorization endpoint. The user logs in to the authoriza= tion server through the web browser, approves this copy of your app, and ge= ts redirected to "myapp://oauthcallback?code=3Dbasdf132".=0A Your app grabs= the "myapp://" url and plucks the authorization code off the end of it. Yo= ur app then takes that code and sends it in the background to the token end= point to exchange for a token.=0A
=0A
=0ASome key points:
=0A
= =0A1) You need to have access to a web browser on the platform, and it's co= nsidered best practice to push the user to the external browser application= on the platform instead of embedding one. There are a couple paragraphs in= the spec's security considerations=0A section that talk about this.
=0A= 2) Your app is "public" because you can't publish it with a secret at confi= guration time. It can, however, keep the tokens secret at runtime.
=0A3)= You need to be very careful with how you store the tokens on the device --= they need to be in a trusted space where other apps on the device can't sn= iff them out.
=0A4) Another app can try to register "myapp://" and inter= cept your code on the way through, so make sure your codes are all one time= use and short lived.
=0A
=0ANone of this is just theoretically possi= ble, people are doing it today. What libraries and stuff you'd be after dep= ends wholly on your platform (both server and client side).=0A
=0A
= =0A -- Justin
=0A
=0AOn 04/12/2012 03:01 PM, Lewis Adam-CAL022 w= rote:
=0A
Hi all,
=0A
 
=0A
I=E2=80=99ve been talkin= g to some of you off line about this already, but I need some help in terms= of implementation.  I would like to use OAuth as a means to get eithe= r a JWT or SAML token to a client running on=0A a handheld device.  Th= is is something that I=E2=80=99m looking to prototype (as part of a larger = project) beginning this week.  So, it is important to me to understand= the divide between what is theoretically possible and what is actually pos= sible.
=0A
 
=0A
Anybody aware of any implementations = out there, either vendor or open source, that I can use for this? =0A
 
=0A
Tx!
=0Aadam
=0A

=0A
=0A
=0A
=0A
_______________________________________________
=0A= 
OAuth mailing list
=0A
OAuth@iet=
f.org
=0A
https://www.ietf.org/mailman/listin=
fo/oauth
=0A
 
=0A
=0A=0A

_____= __________________________________________
OAuth mailing list
OAuth@ietf.org=
https://www.ietf.org/mailman/listinfo/oauth


<= /div>
---1036955950-64407182-1334877670=:64827-- From paulej@packetizer.com Thu Apr 19 20:15:50 2012 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 8CCBA11E80AA; Thu, 19 Apr 2012 20:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB5JhpJJUNTQ; Thu, 19 Apr 2012 20:15:49 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BFB7111E8091; Thu, 19 Apr 2012 20:15:49 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3K3FOei027893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Apr 2012 23:15:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334891726; bh=rqC0GCbqmjz87DbVLUdMN3El0bP0BQKOr8kpRLDxfIQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=FiLSoPbOrVLXkWG/mWfZIGkS0W21qFIyIrxyOiS3atUJHYR5/4ce2/it72pQoBQkW koS7ZfcSKVR7ZOjrurpFYZbSpEn4yAmwoZANbpbbhVWy1UgNVP7yd7ptKj53J3Nsqx DksdbXkT1/Zy/oUyU0CdV5TE/D+nz8jeQMUFoz9w= From: "Paul E. Jones" To: "'Mike Jones'" , "'Murray S. Kucherawy'" , , "'Apps Discuss'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Thu, 19 Apr 2012 23:15:45 -0400 Message-ID: <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTuV7eKz0A== Content-Language: en-us Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 03:15:50 -0000 Mike, > There are two criteria that I would consider to be essential requirements > for any resulting general-purpose discovery specification: > > 1. Being able to always discover per-user information with a single GET > (minimizing user interface latency for mobile devices, etc.) WF can do that. See: $ curl -v https://packetizer.com/.well-known/\ host-meta.json?resource=acct:paulej@packetizer.com > 2. JSON should be required and it should be the only format required > (simplicity and ease of deployment/adoption) See the above example. However, I also support XML with my server. It took me less than 10 minutes to code up both XML and JSON representations. Once the requested format is determined, the requested URI is determined, data is pulled from the database, spitting out the desired format is trivial. Note, and very important note: supporting both XML and JSON would only be a server-side requirement. The client is at liberty to use the format it prefers. I would agree that forcing a client to support both would be unacceptable, but the server? Nothing to it. > SWD already meets those requirements. If the resulting spec meets those > requirements, it doesn't matter a lot whether we call it WebFinger or > Simple Web Discovery, but I believe that the requirements discussion is > probably the most productive one to be having at this point - not the > starting point document. I believe WebFinger meets those requirements. We could debate whether XML should be supported, but I'll note (again) that it is there in RFC 6415. That document isn't all that old and, frankly, it concerns me that we would have a strong preference for format A one week and then Format B the next. We are where we are and I can see reason for asking for JSON, but no good reason to say we should not allow XML (on the server side). Paul From paulej@packetizer.com Thu Apr 19 22:01:05 2012 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 51C6721F8441; Thu, 19 Apr 2012 22:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kid846gV3-41; Thu, 19 Apr 2012 22:01:04 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9A421F852D; Thu, 19 Apr 2012 21:43:31 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3K4gl4d030202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 00:42:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334896969; bh=v0AuuV0Q5NlqXAt4TVgoXLPxImzeLDpP1syOQVU5Qt8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Hs8g8HR9CFhhbg3P+SWCBQiLSI/gRTG3s4eh7/9C7GcXYzZvIzpbD9tNBfl9Xl8n6 oSSQMkRIKpQ8SVX9p/6iIS2LCCSaypRAXSutWDbE8UNOqAAH7BP3tbknh+RCA39oMM KXS4j9aseFbTZ3j6gQA+JKerFjQ2UnmfZScI1W/M= From: "Paul E. Jones" To: "'Tim Bray'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> In-Reply-To: Date: Fri, 20 Apr 2012 00:43:08 -0400 Message-ID: <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NldEdewA= Content-Language: en-us Cc: oauth@ietf.org, 'Apps Discuss' Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 05:01:05 -0000 Tim, I do not agree that it's harmful. If I removed the WF discussion off the table, I'm still having a hard time buying into everything you said in = the blog post. I implement various web services, largely for my own use. Usually, I implement all of them in XML, JSON, plain text (attribute/value pairs), = AND JavaScript (for JSONP). For simple services, it's not hard. I do it because I sometimes have different wants/desires on the client side. = (For more complex ones, I use XML.) For your point (1): For WebFinger, the format is simple. The XRD and JRD definitions exist = and are clearly defined. I think the definitions of each are natural. It's = not hard to produce both. =20 For your point (2): That's a bias you have against XML, no two ways about it. I tend to = prefer to run XML through a sax-style parser and pull out what I want. But, = doing data binding is reasonable if one is dealing with complex data = structures. WebFinger is not so complex that it would need to be done that way, but = so what if developers did? It's their code. A lot of web services have = been written that way, so let developers choose. You conclude with "use JSON". By that logic, we should send the HTML5 = team back to the drawing board and have then re-write it in JSON. Oh, HTML = is a document format. Complex JSON isn't? I'd argue it is whatever you want = to put in it. In any case, I'm not going to object if the consensus of the group is to abandon XML entirely. I personally do not care which format(s) we use. What bothers me, though, is that we put a stake in the ground a few = years ago and people were happy until *very* recently. Now, we want to pull = it out of the ground and put in a whole new one. Engineering protocols should involve thinking far down the road. I = cannot fault anyone for having selected XML at the outset. I cannot fault = anyone for wanting to add JSON support now for something this simple to = implement on the server. However, what I call dangerous is declaring that JSON = should be the only format for the web, ignoring the significant investment web developers have in XML. The motivation for JSON? Because it works well with JavaScript, in spite of the fact that nobody would want to do an = eval on it, so it has to be parsed like any other format? What about the = next web language? Would we invent a new format for that, too? This is like throwing out a widely deploy authentication protocol and re-inventing that wheel, too. Oh yeah... that would be what was done = with OpenID Connect ;-) Seriously... is there no sense of maintaining backward compatibility and rigidly defining protocols for the long-term? Paul > -----Original Message----- > From: Tim Bray [mailto:tbray@textuality.com] > Sent: Thursday, April 19, 2012 11:41 PM > To: Paul E. Jones > Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery > (SWD) >=20 > No. Supporting two different on-the-wire data formats is actively = harmful. > Here are two pieces which explain why: >=20 > - mnot, this month: > http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide > - Me, back in 2009 >=20 > Pick one. -T >=20 > On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones > wrote: > > Mike, > > > >> There are two criteria that I would consider to be essential > >> requirements for any resulting general-purpose discovery = specification: > >> > >> 1. =A0Being able to always discover per-user information with a = single > >> GET (minimizing user interface latency for mobile devices, etc.) > > > > WF can do that. =A0See: > > $ curl -v https://packetizer.com/.well-known/\ > > =A0 =A0 =A0 =A0 = =A0host-meta.json?resource=3Dacct:paulej@packetizer.com > > > >> 2. =A0JSON should be required and it should be the only format = required > >> (simplicity and ease of deployment/adoption) > > > > See the above example. =A0However, I also support XML with my = server. > > It took me less than 10 minutes to code up both XML and JSON > > representations. =A0Once the requested format is determined, the > > requested URI is determined, data is pulled from the database, = spitting > out the desired format is trivial. > > > > Note, and very important note: supporting both XML and JSON would = only > > be a server-side requirement. =A0The client is at liberty to use the > > format it prefers. =A0I would agree that forcing a client to support > > both would be unacceptable, but the server? =A0Nothing to it. > > > >> SWD already meets those requirements. =A0If the resulting spec = meets > >> those requirements, it doesn't matter a lot whether we call it > >> WebFinger or Simple Web Discovery, but I believe that the > >> requirements discussion is probably the most productive one to be > >> having at this point - not the starting point document. > > > > I believe WebFinger meets those requirements. =A0We could debate = whether > > XML should be supported, but I'll note (again) that it is there in = RFC > 6415. > > That document isn't all that old and, frankly, it concerns me that = we > > would have a strong preference for format A one week and then Format = B > the next. > > We are where we are and I can see reason for asking for JSON, but no > > good reason to say we should not allow XML (on the server side). > > > > Paul > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss From Michael.Jones@microsoft.com Thu Apr 19 22:09:57 2012 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 BB4EC21F8704; Thu, 19 Apr 2012 22:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.854 X-Spam-Level: X-Spam-Status: No, score=-3.854 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6p22CaNFdeB; Thu, 19 Apr 2012 22:09:56 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id B13AE21F86A7; Thu, 19 Apr 2012 22:09:52 -0700 (PDT) Received: from mail124-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Apr 2012 05:09:51 +0000 Received: from mail124-ch1 (localhost [127.0.0.1]) by mail124-ch1-R.bigfish.com (Postfix) with ESMTP id AF0B82069F; Fri, 20 Apr 2012 05:09:51 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I542M1432Nzz1202hzz1033IL8275bhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail124-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail124-ch1 (localhost.localdomain [127.0.0.1]) by mail124-ch1 (MessageSwitch) id 1334898590187963_3162; Fri, 20 Apr 2012 05:09:50 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail124-ch1.bigfish.com (Postfix) with ESMTP id 21235100045; Fri, 20 Apr 2012 05:09:50 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Apr 2012 05:09:49 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0283.004; Fri, 20 Apr 2012 05:09:48 +0000 From: Mike Jones To: "Paul E. Jones" , "'Murray S. Kucherawy'" , "oauth@ietf.org" , 'Apps Discuss' Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHqPloXuSZ0jfOECvbryHsEgTK5ajKa7Q Date: Fri, 20 Apr 2012 05:09:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> In-Reply-To: <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 05:09:57 -0000 Currently, support for the "resource" parameter is optional, as per the fol= lowing (correct?): Note that support for the "resource" parameter is optional, but strongly RECOMMENDED for improved performance. If a server does not implement the "resource" parameter, then the server's host metadata processing logic remains unchanged from RFC 6415. To truly support 1, this would need to be changed to REQUIRED, correct? -- Mike -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com]=20 Sent: Thursday, April 19, 2012 8:16 PM To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) Mike, > There are two criteria that I would consider to be essential=20 > requirements for any resulting general-purpose discovery specification: >=20 > 1. Being able to always discover per-user information with a single=20 > GET (minimizing user interface latency for mobile devices, etc.) WF can do that. See: $ curl -v https://packetizer.com/.well-known/\ host-meta.json?resource=3Dacct:paulej@packetizer.com =20 > 2. JSON should be required and it should be the only format required=20 > (simplicity and ease of deployment/adoption) See the above example. However, I also support XML with my server. It too= k me less than 10 minutes to code up both XML and JSON representations. On= ce the requested format is determined, the requested URI is determined, dat= a is pulled from the database, spitting out the desired format is trivial. =20 Note, and very important note: supporting both XML and JSON would only be a= server-side requirement. The client is at liberty to use the format it pr= efers. I would agree that forcing a client to support both would be unacce= ptable, but the server? Nothing to it. =20 > SWD already meets those requirements. If the resulting spec meets=20 > those requirements, it doesn't matter a lot whether we call it=20 > WebFinger or Simple Web Discovery, but I believe that the requirements=20 > discussion is probably the most productive one to be having at this=20 > point - not the starting point document. I believe WebFinger meets those requirements. We could debate whether XML = should be supported, but I'll note (again) that it is there in RFC 6415. That document isn't all that old and, frankly, it concerns me that we would= have a strong preference for format A one week and then Format B the next. We are where we are and I can see reason for asking for JSON, but no good r= eason to say we should not allow XML (on the server side). Paul From ve7jtb@ve7jtb.com Thu Apr 19 22:15:50 2012 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 88E0921F846E for ; Thu, 19 Apr 2012 22:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx4fO0NnddfM for ; Thu, 19 Apr 2012 22:15:50 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9803921F845E for ; Thu, 19 Apr 2012 22:15:49 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so219792wib.13 for ; Thu, 19 Apr 2012 22:15:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=351gmXCEbxfLdlLYqNzXCL99Fg3bI2M190ZR2J33tNs=; b=XYWQnydUATX2Dj9LwuScOVnZV3qKPHNXOITYBqqtEC8HQpsvYLjX0Ut+pEa2WalLxR CyF4EXSp6+R9dFDS2uuB1IaJcdZIb2kV3Mb64Vu7dGsi3nkJHIbIqsn5IXJcYV0f2GWe eHw+0OgYgvagqtOTUyWqHpqS5bX3nCJ+ZjnKwWWlN7VQocgDrEWSXsljxhZZKo+xr7XQ Yh73a/mfv6ebxxR/aYQS/4pl3wEfw1X+i2iGbs865GWhFeWSWtWbtMfDml4vo6uAmuNA fktJdwlzo9/eeTwkWCJt9m9ItlPbBFTDLzdW9YuzeT/UUlOwvpsSZSRNhwZSe1W+IaA/ Cmdw== Received: by 10.180.78.105 with SMTP id a9mr2656159wix.20.1334898948301; Thu, 19 Apr 2012 22:15:48 -0700 (PDT) Received: from [10.39.249.209] (ip-109-43-0-81.web.vodafone.de. [109.43.0.81]) by mx.google.com with ESMTPS id l5sm2806560wia.11.2012.04.19.22.15.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 22:15:46 -0700 (PDT) References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F905348.9090505@alcatel-lucent.com> In-Reply-To: <4F905348.9090505@alcatel-lucent.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1C31A98B-8649-457A-93B3-A3C35DDB2A77; protocol="application/pkcs7-signature" Message-Id: <323A4E4B-CB04-419A-9606-0EFC06603813@ve7jtb.com> X-Mailer: iPhone Mail (9B179) From: John Bradley Date: Fri, 20 Apr 2012 07:15:58 +0200 To: "igor.faynberg@alcatel-lucent.com" X-Gm-Message-State: ALoCoQmgJp/F/Wf+coerhbtBzgV7shgAMLD/clzj+8u24aa8dMZNLZWJEGp8JSrMq1tpL/Gbm3oI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 05:15:50 -0000 --Apple-Mail-1C31A98B-8649-457A-93B3-A3C35DDB2A77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree, requirements are more important than deciding on the starting docu= ment at this point.=20 I don't care about the name at all. The proposals are not wolds apart.=20 I suspect if we can agree on the requirements for the number of requests mos= t of the other decisions will fall out of that.=20 John Bradley Sent from my iPhone On 2012-04-19, at 8:02 PM, Igor Faynberg w= rote: > +1 on the requirements. >=20 > On 4/19/2012 12:48 PM, Mike Jones wrote: >> There are two criteria that I would consider to be essential requirements= for any resulting general-purpose discovery specification: >>=20 >> 1. Being able to always discover per-user information with a single GET (= minimizing user interface latency for mobile devices, etc.) >>=20 >> 2. JSON should be required and it should be the only format required (si= mplicity and ease of deployment/adoption) >>=20 >> SWD already meets those requirements. If the resulting spec meets those r= equirements, it doesn't matter a lot whether we call it WebFinger or Simple W= eb Discovery, but I believe that the requirements discussion is probably the= most productive one to be having at this point - not the starting point doc= ument. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Murray S. Kucherawy >> Sent: Thursday, April 19, 2012 9:32 AM >> To: oauth@ietf.org WG; Apps Discuss >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discover= y (SWD) >>=20 >> By all means people should correct me if they think I'm wrong about this,= but so far from monitoring the discussion there seems to be general support= for focusing on WebFinger and developing it to meet the needs of those who h= ave deployed SWD, versus the opposite. >>=20 >> Does anyone want to argue the opposite? >>=20 >> -MSK, appsawg co-chair >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail-1C31A98B-8649-457A-93B3-A3C35DDB2A77 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MjAwNTE2MDFaMCMGCSqGSIb3DQEJBDEWBBRr2qvt U3FywRp1ebnGTq1vuPsy8jCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQBCi3yWgSuA/dprKMEiM34D3oQV3dJ8B1we/tjR lvQ9l6R+1aSbh0QSNZQEEwoNwOAoe++HUWExhdeE4W55KXx7H5RssCdyyTZ8TAFD80xSLABcYr4E ZYlpyJTJ/v7YsxXmHDAGzlThvQzxDUUbLu4uAdqQ11aLoW5qncQsz8mq2jrxxDnAWkj3YIoKGo02 5rWPCQNOV9NawGv8MMKtud9jbP588hX3myXpbl1yRp6VR6ZokX48+4Y6IReartjCEcMhCNGxutFO bplk1pMplBxdEVg2CTCwzWB0YNz7p5q95jVes+b+6Cx/LvsIaZ6bh0DDjrpmzqAyHFlOCnQF+V8b AAAAAAAA --Apple-Mail-1C31A98B-8649-457A-93B3-A3C35DDB2A77-- From paulej@packetizer.com Thu Apr 19 22:38:48 2012 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 B990D21F872B; Thu, 19 Apr 2012 22:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-WdaNGhxaBb; Thu, 19 Apr 2012 22:38:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D859F21F872A; Thu, 19 Apr 2012 22:38:47 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3K5cN7P032249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 01:38:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334900303; bh=iMhXoylNK0C9bebVHnLyn8y8prDDb3947UYXYdF0tew=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Nsdi+AQNfCFkniA+m8yO9w56GJywtRLxSAUUM9gT8ZuXve6JGPjiCq+M3xh5lbT/C dmWY/SZ7V25Lq623ntZQl4/UV63+j0jydrLL/wIp729gfkfXJwYj8//Dgsj2oPY+jz fqs+FkOhPZuKyF8OWrzp3eoy5i+z0QdVIOheIc+g= From: "Paul E. Jones" To: "'Mike Jones'" , "'Murray S. Kucherawy'" , , "'Apps Discuss'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 20 Apr 2012 01:38:44 -0400 Message-ID: <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAI8MBwxldDdyNA= Content-Language: en-us Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 05:38:48 -0000 That's correct. We could certainly make it mandatory, but the reason it isn't is to maintain backward compatibility with existing deployments. I think we should always think carefully when we decide to make a change that breaks backward-compatibility. This is one change that would do that. Paul > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, April 20, 2012 1:10 AM > To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > Currently, support for the "resource" parameter is optional, as per the > following (correct?): > > Note that support for the "resource" parameter is optional, but > strongly RECOMMENDED for improved performance. If a server does not > implement the "resource" parameter, then the server's host metadata > processing logic remains unchanged from RFC 6415. > > To truly support 1, this would need to be changed to REQUIRED, correct? > > -- Mike > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, April 19, 2012 8:16 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > Mike, > > > There are two criteria that I would consider to be essential > > requirements for any resulting general-purpose discovery specification: > > > > 1. Being able to always discover per-user information with a single > > GET (minimizing user interface latency for mobile devices, etc.) > > WF can do that. See: > $ curl -v https://packetizer.com/.well-known/\ > host-meta.json?resource=acct:paulej@packetizer.com > > > 2. JSON should be required and it should be the only format required > > (simplicity and ease of deployment/adoption) > > See the above example. However, I also support XML with my server. It > took me less than 10 minutes to code up both XML and JSON representations. > Once the requested format is determined, the requested URI is determined, > data is pulled from the database, spitting out the desired format is > trivial. > > Note, and very important note: supporting both XML and JSON would only be > a server-side requirement. The client is at liberty to use the format it > prefers. I would agree that forcing a client to support both would be > unacceptable, but the server? Nothing to it. > > > SWD already meets those requirements. If the resulting spec meets > > those requirements, it doesn't matter a lot whether we call it > > WebFinger or Simple Web Discovery, but I believe that the requirements > > discussion is probably the most productive one to be having at this > > point - not the starting point document. > > I believe WebFinger meets those requirements. We could debate whether XML > should be supported, but I'll note (again) that it is there in RFC 6415. > That document isn't all that old and, frankly, it concerns me that we > would have a strong preference for format A one week and then Format B the > next. > We are where we are and I can see reason for asking for JSON, but no good > reason to say we should not allow XML (on the server side). > > Paul > > > From paulej@packetizer.com Thu Apr 19 22:48:46 2012 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 768AD21F8731; Thu, 19 Apr 2012 22:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Amm-9beAGPd; Thu, 19 Apr 2012 22:48:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id ACE8121F8730; Thu, 19 Apr 2012 22:48:42 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3K5mdTa032547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 01:48:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334900920; bh=fDhoFqJvC3YpUrdEfZWdn8/Mid0lQrrSJvUesZ083PQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=g/GUnMtcs0wY7SB0zKN4Y33IX9d2rSeljUMMkfQV0YVyym/apDdEUO2GPQKkBKJCO Q9L8I8JzegQN6k7EM+q5Wxysf78llfvTbzbkp4I8morGhdH8FcLpMoD5zl3ef9fqfQ S2HZtyAoC0ddAR2Zr5xShxSGDfjr4qVt5tVn/Yco= From: "Paul E. Jones" To: "'Tim Bray'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> In-Reply-To: Date: Fri, 20 Apr 2012 01:49:00 -0400 Message-ID: <092501cd1eb9$49a31520$dce93f60$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCTYzvFJW0q2ug Content-Language: en-us Cc: oauth@ietf.org, 'Apps Discuss' Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 05:48:46 -0000 Tim, I misunderstood. I thought you authored the MNOT blog post. That stood = in quite a contrast to your work on XML. Reading that, I felt like, on a = whim, you threw the baby out with the bathwater and started down a new path, giving no regard to what exists. OK, let me reset me mind dizzy head here... What I do understand is you're suggesting for WF, we should pick one. = It there was any complexity to it, I'd agree with you. But, in all seriousness, producing both XML and JSON for WF is a trivial exercise. = Why not support both and avoid breaking what exists today? Asking servers = to add JSON would be easy enough to do. Paul > -----Original Message----- > From: Tim Bray [mailto:tbray@textuality.com] > Sent: Friday, April 20, 2012 1:33 AM > To: Paul E. Jones > Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss > Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery > (SWD) >=20 > Oops, looks like I left off the link to my own remarks about XML&JSON: > http://goo.gl/v7Pjr - but they say the same thing, more or less, that = MNot > did. Your characterizing me as an enemy of XML is amusing, given that = my > name appears at the top of this document: http://goo.gl/lBjkl >=20 > The points 1 & 2 you=92re reacting to are from someone else. But we = agree > that the choice of formats isn=92t crucial. Where we disagree is that = we > should pick just one, not multiple ones. -T >=20 > On Thu, Apr 19, 2012 at 9:43 PM, Paul E. Jones > wrote: > > Tim, > > > > I do not agree that it's harmful. If I removed the WF discussion off > > the table, I'm still having a hard time buying into everything you > > said in the blog post. > > > > I implement various web services, largely for my own use. = =A0Usually, I > > implement all of them in XML, JSON, plain text (attribute/value > > pairs), AND JavaScript (for JSONP). =A0For simple services, it's not > > hard. =A0I do it because I sometimes have different wants/desires on = the > > client side. =A0(For more complex ones, I use XML.) > > > > For your point (1): > > For WebFinger, the format is simple. =A0The XRD and JRD definitions > > exist and are clearly defined. =A0I think the definitions of each = are > > natural. =A0It's not hard to produce both. > > > > For your point (2): > > That's a bias you have against XML, no two ways about it. =A0I tend = to > > prefer to run XML through a sax-style parser and pull out what I = want. > > But, doing data binding is reasonable if one is dealing with complex > data structures. > > WebFinger is not so complex that it would need to be done that way, > > but so what if developers did? =A0It's their code. =A0A lot of web > > services have been written that way, so let developers choose. > > > > You conclude with "use JSON". =A0By that logic, we should send the = HTML5 > > team back to the drawing board and have then re-write it in JSON. = =A0Oh, > > HTML is a document format. =A0Complex JSON isn't? =A0I'd argue it is > > whatever you want to put in it. > > > > In any case, I'm not going to object if the consensus of the group = is > > to abandon XML entirely. =A0I personally do not care which format(s) = we > use. > > What bothers me, though, is that we put a stake in the ground a few > > years ago and people were happy until *very* recently. =A0Now, we = want > > to pull it out of the ground and put in a whole new one. > > > > Engineering protocols should involve thinking far down the road. = =A0I > > cannot fault anyone for having selected XML at the outset. =A0I = cannot > > fault anyone for wanting to add JSON support now for something this > > simple to implement on the server. =A0However, what I call dangerous = is > > declaring that JSON should be the only format for the web, ignoring > > the significant investment web developers have in XML. =A0The = motivation > > for JSON? =A0Because it works well with JavaScript, in spite of the = fact > > that nobody would want to do an eval on it, so it has to be parsed > > like any other format? =A0What about the next web language? =A0Would = we > invent a new format for that, too? > > > > This is like throwing out a widely deploy authentication protocol = and > > re-inventing that wheel, too. =A0Oh yeah... that would be what was = done > > with OpenID Connect ;-) > > > > Seriously... is there no sense of maintaining backward compatibility > > and rigidly defining protocols for the long-term? > > > > Paul > > > >> -----Original Message----- > >> From: Tim Bray [mailto:tbray@textuality.com] > >> Sent: Thursday, April 19, 2012 11:41 PM > >> To: Paul E. Jones > >> Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss > >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > >> Discovery > >> (SWD) > >> > >> No. Supporting two different on-the-wire data formats is actively > harmful. > >> Here are two pieces which explain why: > >> > >> - mnot, this month: > >> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide > >> - Me, back in 2009 > >> > >> Pick one. -T > >> > >> On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones > >> > >> wrote: > >> > Mike, > >> > > >> >> There are two criteria that I would consider to be essential > >> >> requirements for any resulting general-purpose discovery > specification: > >> >> > >> >> 1. =A0Being able to always discover per-user information with a > >> >> single GET (minimizing user interface latency for mobile = devices, > >> >> etc.) > >> > > >> > WF can do that. =A0See: > >> > $ curl -v https://packetizer.com/.well-known/\ > >> > =A0 =A0 =A0 =A0 = =A0host-meta.json?resource=3Dacct:paulej@packetizer.com > >> > > >> >> 2. =A0JSON should be required and it should be the only format > >> >> required (simplicity and ease of deployment/adoption) > >> > > >> > See the above example. =A0However, I also support XML with my = server. > >> > It took me less than 10 minutes to code up both XML and JSON > >> > representations. =A0Once the requested format is determined, the > >> > requested URI is determined, data is pulled from the database, > >> > spitting > >> out the desired format is trivial. > >> > > >> > Note, and very important note: supporting both XML and JSON would > >> > only be a server-side requirement. =A0The client is at liberty to = use > >> > the format it prefers. =A0I would agree that forcing a client to > >> > support both would be unacceptable, but the server? =A0Nothing to = it. > >> > > >> >> SWD already meets those requirements. =A0If the resulting spec = meets > >> >> those requirements, it doesn't matter a lot whether we call it > >> >> WebFinger or Simple Web Discovery, but I believe that the > >> >> requirements discussion is probably the most productive one to = be > >> >> having at this point - not the starting point document. > >> > > >> > I believe WebFinger meets those requirements. =A0We could debate > >> > whether XML should be supported, but I'll note (again) that it is > >> > there in RFC > >> 6415. > >> > That document isn't all that old and, frankly, it concerns me = that > >> > we would have a strong preference for format A one week and then > >> > Format B > >> the next. > >> > We are where we are and I can see reason for asking for JSON, but > >> > no good reason to say we should not allow XML (on the server = side). > >> > > >> > Paul > >> > > >> > > >> > _______________________________________________ > >> > apps-discuss mailing list > >> > apps-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > > From Michael.Jones@microsoft.com Thu Apr 19 22:48:58 2012 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 D9B2221E8037; Thu, 19 Apr 2012 22:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.845 X-Spam-Level: X-Spam-Status: No, score=-3.845 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAj3L4UVjWI2; Thu, 19 Apr 2012 22:48:58 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id C21C421E8027; Thu, 19 Apr 2012 22:48:56 -0700 (PDT) Received: from mail71-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Apr 2012 05:48:55 +0000 Received: from mail71-am1 (localhost [127.0.0.1]) by mail71-am1-R.bigfish.com (Postfix) with ESMTP id BF95B1C046F; Fri, 20 Apr 2012 05:48:55 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371I542M1432Nzz1202hzz1033IL8275bhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail71-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail71-am1 (localhost.localdomain [127.0.0.1]) by mail71-am1 (MessageSwitch) id 1334900933255990_30730; Fri, 20 Apr 2012 05:48:53 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.237]) by mail71-am1.bigfish.com (Postfix) with ESMTP id 3A2443C00B0; Fri, 20 Apr 2012 05:48:53 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Apr 2012 05:48:52 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0283.004; Fri, 20 Apr 2012 05:48:50 +0000 From: Mike Jones To: "Paul E. Jones" , "'Murray S. Kucherawy'" , "oauth@ietf.org" , 'Apps Discuss' Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: AQHNHqPloXuSZ0jfOECvbryHsEgTK5ajKa7QgAAIvQCAAAHJYA== Date: Fri, 20 Apr 2012 05:48:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> In-Reply-To: <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 05:48:59 -0000 To be clear, making this mandatory would break no clients. It would requir= e updating some servers, just as requiring JSON would. This seems like a f= air tradeoff when it makes an appreciable difference in user interface late= ncy in some important scenarios. If you and the other key WebFinger suppor= ters can agree to making "resource" support mandatory and requiring JSON, I= believe we may have a path forward. Cheers, -- Mike -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com]=20 Sent: Thursday, April 19, 2012 10:39 PM To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery = (SWD) That's correct. We could certainly make it mandatory, but the reason it is= n't is to maintain backward compatibility with existing deployments. I think we should always think carefully when we decide to make a change th= at breaks backward-compatibility. This is one change that would do that. Paul > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, April 20, 2012 1:10 AM > To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 > Discovery > (SWD) >=20 > Currently, support for the "resource" parameter is optional, as per=20 > the following (correct?): >=20 > Note that support for the "resource" parameter is optional, but > strongly RECOMMENDED for improved performance. If a server does not > implement the "resource" parameter, then the server's host metadata > processing logic remains unchanged from RFC 6415. >=20 > To truly support 1, this would need to be changed to REQUIRED, correct? >=20 > -- Mike >=20 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, April 19, 2012 8:16 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 > Discovery > (SWD) >=20 > Mike, >=20 > > There are two criteria that I would consider to be essential=20 > > requirements for any resulting general-purpose discovery specification: > > > > 1. Being able to always discover per-user information with a single=20 > > GET (minimizing user interface latency for mobile devices, etc.) >=20 > WF can do that. See: > $ curl -v https://packetizer.com/.well-known/\ > host-meta.json?resource=3Dacct:paulej@packetizer.com >=20 > > 2. JSON should be required and it should be the only format=20 > > required (simplicity and ease of deployment/adoption) >=20 > See the above example. However, I also support XML with my server. =20 > It took me less than 10 minutes to code up both XML and JSON representati= ons. > Once the requested format is determined, the requested URI is=20 > determined, data is pulled from the database, spitting out the desired=20 > format is trivial. >=20 > Note, and very important note: supporting both XML and JSON would only=20 > be a server-side requirement. The client is at liberty to use the=20 > format it prefers. I would agree that forcing a client to support=20 > both would be unacceptable, but the server? Nothing to it. >=20 > > SWD already meets those requirements. If the resulting spec meets=20 > > those requirements, it doesn't matter a lot whether we call it=20 > > WebFinger or Simple Web Discovery, but I believe that the=20 > > requirements discussion is probably the most productive one to be=20 > > having at this point - not the starting point document. >=20 > I believe WebFinger meets those requirements. We could debate whether=20 > XML should be supported, but I'll note (again) that it is there in RFC 64= 15. > That document isn't all that old and, frankly, it concerns me that we=20 > would have a strong preference for format A one week and then Format B=20 > the next. > We are where we are and I can see reason for asking for JSON, but no=20 > good reason to say we should not allow XML (on the server side). >=20 > Paul >=20 >=20 >=20 From paulej@packetizer.com Thu Apr 19 23:00:18 2012 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 7965421E8036; Thu, 19 Apr 2012 23:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAxrhmVLszKU; Thu, 19 Apr 2012 23:00:13 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 20FF721E8025; Thu, 19 Apr 2012 23:00:13 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3K60BEM000403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 02:00:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334901612; bh=R42V2chsFu3YMfrOM/24Vskuzm5hsMsHQCgm89/IYok=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=d5OcegZgoc9d022t0AnC3XxwEISYfMqY41pT+yarGAc5ynU+oDia/4HWArvaVwM6s pmj7KL2ml96Nqxs+5EEyXgFp4mWWgRCqYODF2Uj8vrzOXwO8TcTO+mkuheRPzl7qS3 OklgTlU9m/CeDJrAzvQxzp8s0QzaBBtoG1ayWPLw= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , "'Tim Bray'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> In-Reply-To: Date: Fri, 20 Apr 2012 02:00:33 -0400 Message-ID: <092701cd1eba$e6447990$b2cd6cb0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCTYzvFAFRPsjalaomNgA= Content-Language: en-us Cc: oauth@ietf.org, 'Apps Discuss' Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 06:00:18 -0000 Oh, don't scare people with that ;-) If we do extend the syntax of WF, we should ensure that both formats are extended in a natural way for each format. Backward compatibility = should also be of utmost concern, so changes should never be too drastic. Paul > -----Original Message----- > From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] > Sent: Friday, April 20, 2012 1:49 AM > To: Tim Bray; Paul E. Jones > Cc: oauth@ietf.org; Apps Discuss > Subject: R: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery > (SWD) >=20 > I also would be in favor of keeping both, for the reasons mentioned. = Plus > xml is traditionally better than json at handling extensions & = namespaces > that may appear throughout future deployments >=20 > walter >=20 > > -----Messaggio originale----- > > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] Per conto di Tim Bray > > Inviato: venerd=EC 20 aprile 2012 7.33 > > A: Paul E. Jones > > Cc: oauth@ietf.org; Apps Discuss > > Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > > Discovery (SWD) > > > > Oops, looks like I left off the link to my own remarks about = XML&JSON: > > http://goo.gl/v7Pjr - but they say the same thing, more or less, = that > > MNot did. Your characterizing me as an enemy of XML is amusing, = given > > that my name appears at the top of this document: = http://goo.gl/lBjkl > > > > The points 1 & 2 you're reacting to are from someone else. But we > > agree that the choice of formats isn't crucial. Where we disagree is > > that we should pick just one, not multiple ones. -T > > > > On Thu, Apr 19, 2012 at 9:43 PM, Paul E. Jones = > > wrote: > > > Tim, > > > > > > I do not agree that it's harmful. If I removed the WF discussion = off > > the > > > table, I'm still having a hard time buying into everything you = said > > in the > > > blog post. > > > > > > I implement various web services, largely for my own use. = Usually, > > > I implement all of them in XML, JSON, plain text (attribute/value > > pairs), AND > > > JavaScript (for JSONP). For simple services, it's not hard. I do > > > it because I sometimes have different wants/desires on the client > side. > > (For > > > more complex ones, I use XML.) > > > > > > For your point (1): > > > For WebFinger, the format is simple. The XRD and JRD definitions > > exist and > > > are clearly defined. I think the definitions of each are natural. > > It's not > > > hard to produce both. > > > > > > For your point (2): > > > That's a bias you have against XML, no two ways about it. I tend = to > > prefer > > > to run XML through a sax-style parser and pull out what I want. > > > But, > > doing > > > data binding is reasonable if one is dealing with complex data > > structures. > > > WebFinger is not so complex that it would need to be done that = way, > > but so > > > what if developers did? It's their code. A lot of web services > > > have > > been > > > written that way, so let developers choose. > > > > > > You conclude with "use JSON". By that logic, we should send the > > HTML5 team > > > back to the drawing board and have then re-write it in JSON. Oh, > > HTML is a > > > document format. Complex JSON isn't? I'd argue it is whatever = you > > want to > > > put in it. > > > > > > In any case, I'm not going to object if the consensus of the group > > > is > > to > > > abandon XML entirely. I personally do not care which format(s) we > > use. > > > What bothers me, though, is that we put a stake in the ground a = few > > years > > > ago and people were happy until *very* recently. Now, we want to > > pull it > > > out of the ground and put in a whole new one. > > > > > > Engineering protocols should involve thinking far down the road. = I > > cannot > > > fault anyone for having selected XML at the outset. I cannot = fault > > anyone > > > for wanting to add JSON support now for something this simple to > > implement > > > on the server. However, what I call dangerous is declaring that > > > JSON > > should > > > be the only format for the web, ignoring the significant = investment > > web > > > developers have in XML. The motivation for JSON? Because it = works > > well > > > with JavaScript, in spite of the fact that nobody would want to do > > > an > > eval > > > on it, so it has to be parsed like any other format? What about = the > > next > > > web language? Would we invent a new format for that, too? > > > > > > This is like throwing out a widely deploy authentication protocol > > > and re-inventing that wheel, too. Oh yeah... that would be what = was > > > done > > with > > > OpenID Connect ;-) > > > > > > Seriously... is there no sense of maintaining backward = compatibility > > and > > > rigidly defining protocols for the long-term? > > > > > > Paul > > > > > >> -----Original Message----- > > >> From: Tim Bray [mailto:tbray@textuality.com] > > >> Sent: Thursday, April 19, 2012 11:41 PM > > >> To: Paul E. Jones > > >> Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss > > >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > > Discovery > > >> (SWD) > > >> > > >> No. Supporting two different on-the-wire data formats is actively > > harmful. > > >> Here are two pieces which explain why: > > >> > > >> - mnot, this month: > > >> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide > > >> - Me, back in 2009 > > >> > > >> Pick one. -T > > >> > > >> On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones > > > > >> wrote: > > >> > Mike, > > >> > > > >> >> There are two criteria that I would consider to be essential > > >> >> requirements for any resulting general-purpose discovery > > specification: > > >> >> > > >> >> 1. Being able to always discover per-user information with a > > single > > >> >> GET (minimizing user interface latency for mobile devices, = etc.) > > >> > > > >> > WF can do that. See: > > >> > $ curl -v https://packetizer.com/.well-known/\ > > >> > host-meta.json?resource=3Dacct:paulej@packetizer.com > > >> > > > >> >> 2. JSON should be required and it should be the only format > > required > > >> >> (simplicity and ease of deployment/adoption) > > >> > > > >> > See the above example. However, I also support XML with my > > server. > > >> > It took me less than 10 minutes to code up both XML and JSON > > >> > representations. Once the requested format is determined, the > > >> > requested URI is determined, data is pulled from the database, > > spitting > > >> out the desired format is trivial. > > >> > > > >> > Note, and very important note: supporting both XML and JSON = would > > only > > >> > be a server-side requirement. The client is at liberty to use > > >> > the format it prefers. I would agree that forcing a client to > > >> > support both would be unacceptable, but the server? Nothing to = it. > > >> > > > >> >> SWD already meets those requirements. If the resulting spec > > meets > > >> >> those requirements, it doesn't matter a lot whether we call it > > >> >> WebFinger or Simple Web Discovery, but I believe that the > > >> >> requirements discussion is probably the most productive one to > > >> >> be having at this point - not the starting point document. > > >> > > > >> > I believe WebFinger meets those requirements. We could debate > > whether > > >> > XML should be supported, but I'll note (again) that it is there > > >> > in > > RFC > > >> 6415. > > >> > That document isn't all that old and, frankly, it concerns me > > >> > that > > we > > >> > would have a strong preference for format A one week and then > > Format B > > >> the next. > > >> > We are where we are and I can see reason for asking for JSON, = but > > no > > >> > good reason to say we should not allow XML (on the server = side). > > >> > > > >> > Paul > > >> > > > >> > > > >> > _______________________________________________ > > >> > apps-discuss mailing list > > >> > apps-discuss@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle > persone indicate. La diffusione, copia o qualsiasi altra azione = derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. > Qualora abbiate ricevuto questo documento per errore siete = cortesemente > pregati di darne immediata comunicazione al mittente e di provvedere = alla > sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain = privileged > information intended for the addressee(s) only. Dissemination, = copying, > printing or use by anybody else is unauthorised. If you are not the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks. From paulej@packetizer.com Thu Apr 19 23:11:07 2012 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 3F24521F846D; Thu, 19 Apr 2012 23:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR449xjD3dnK; Thu, 19 Apr 2012 23:11:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 18F3421F8463; Thu, 19 Apr 2012 23:11:02 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3K6AmnE000772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 02:10:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334902249; bh=othCyOP9etff9WFr1Yh/9mkooo0sN93A+TDF0aO4G0s=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=BZPpSZmWZaqrmnU4JqN46iRUUBwM875yWaPcnAWUX4F7GA5h/jljqGzptzyw75Bev lEBBQO3DU5wKd17sw+LbgD2cK7s7IExIuCfVjXdgpEmhTSzDxdmR9adLuxVB+9nU0m iw2o3FhuiI/XOcxPOcW1/4XayH2nAfE1waPSyUC8= From: "Paul E. Jones" To: "'Mike Jones'" , "'Murray S. Kucherawy'" , , "'Apps Discuss'" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 20 Apr 2012 02:11:10 -0400 Message-ID: <094101cd1ebc$61eb06d0$25c11470$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAI8MBwxAc/xlwgBkQ/oMJW13o4g Content-Language: en-us Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 06:11:07 -0000 Mike, Deal. :-) Paul > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, April 20, 2012 1:49 AM > To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > To be clear, making this mandatory would break no clients. It would > require updating some servers, just as requiring JSON would. This seems > like a fair tradeoff when it makes an appreciable difference in user > interface latency in some important scenarios. If you and the other key > WebFinger supporters can agree to making "resource" support mandatory and > requiring JSON, I believe we may have a path forward. > > Cheers, > -- Mike > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, April 19, 2012 10:39 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery > (SWD) > > That's correct. We could certainly make it mandatory, but the reason it > isn't is to maintain backward compatibility with existing deployments. > > I think we should always think carefully when we decide to make a change > that breaks backward-compatibility. This is one change that would do > that. > > Paul > > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Friday, April 20, 2012 1:10 AM > > To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > > Discovery > > (SWD) > > > > Currently, support for the "resource" parameter is optional, as per > > the following (correct?): > > > > Note that support for the "resource" parameter is optional, but > > strongly RECOMMENDED for improved performance. If a server does not > > implement the "resource" parameter, then the server's host metadata > > processing logic remains unchanged from RFC 6415. > > > > To truly support 1, this would need to be changed to REQUIRED, correct? > > > > -- Mike > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Thursday, April 19, 2012 8:16 PM > > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > > Discovery > > (SWD) > > > > Mike, > > > > > There are two criteria that I would consider to be essential > > > requirements for any resulting general-purpose discovery > specification: > > > > > > 1. Being able to always discover per-user information with a single > > > GET (minimizing user interface latency for mobile devices, etc.) > > > > WF can do that. See: > > $ curl -v https://packetizer.com/.well-known/\ > > host-meta.json?resource=acct:paulej@packetizer.com > > > > > 2. JSON should be required and it should be the only format > > > required (simplicity and ease of deployment/adoption) > > > > See the above example. However, I also support XML with my server. > > It took me less than 10 minutes to code up both XML and JSON > representations. > > Once the requested format is determined, the requested URI is > > determined, data is pulled from the database, spitting out the desired > > format is trivial. > > > > Note, and very important note: supporting both XML and JSON would only > > be a server-side requirement. The client is at liberty to use the > > format it prefers. I would agree that forcing a client to support > > both would be unacceptable, but the server? Nothing to it. > > > > > SWD already meets those requirements. If the resulting spec meets > > > those requirements, it doesn't matter a lot whether we call it > > > WebFinger or Simple Web Discovery, but I believe that the > > > requirements discussion is probably the most productive one to be > > > having at this point - not the starting point document. > > > > I believe WebFinger meets those requirements. We could debate whether > > XML should be supported, but I'll note (again) that it is there in RFC > 6415. > > That document isn't all that old and, frankly, it concerns me that we > > would have a strong preference for format A one week and then Format B > > the next. > > We are where we are and I can see reason for asking for JSON, but no > > good reason to say we should not allow XML (on the server side). > > > > Paul > > > > > > > > > From bcampbell@pingidentity.com Fri Apr 20 05:27:27 2012 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 A268321F86FF for ; Fri, 20 Apr 2012 05:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.955 X-Spam-Level: X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFui2RW2r-lI for ; Fri, 20 Apr 2012 05:27:26 -0700 (PDT) Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id E232721F8670 for ; Fri, 20 Apr 2012 05:27:25 -0700 (PDT) Received: from mail-vb0-f53.google.com ([209.85.212.53]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKT5FWLWnfUyUVKet1ek8pz+uzo831QZKV@postini.com; Fri, 20 Apr 2012 05:27:26 PDT Received: by vbbfc26 with SMTP id fc26so7602753vbb.12 for ; Fri, 20 Apr 2012 05:27:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=NGl3bANYEPAZOzzLjsbZ1TmRDGEtOzdOrmD9gat1FZ0=; b=mNwLvgBHkpB8bPkvxPsx37VdE2nk/nia840Y6WLlXG5ASBikyjJZAsstOZyWlnQ+xj cpiX2b3lYDtqMGqOUMjkmbWcibhqbmbWOPn1/LtQCoN5k/oUGh+R+H53QRpEu08cpb8f nhzEfm0XT0DkpH86vcO2wgsum8WhIK29K0ZqHy1jKqJovX/5GHq5C6GOFwwXOjh3C1BD L546/kTKIiW89I/b/1kvl/LzcVYFzwLUVzqkS3Sr2OA68YRkhNOynGF6Nsy6qIV7sV4w bYL7mY1/va4bmVSD+XEgmxxZdxGjQRGDE/3wBDhAhEQagtL8gMEXY93JQrhFZ+Lij5XG lGfg== Received: by 10.220.38.138 with SMTP id b10mr4472553vce.23.1334924844569; Fri, 20 Apr 2012 05:27:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.38.104 with HTTP; Fri, 20 Apr 2012 05:26:54 -0700 (PDT) In-Reply-To: <59E470B10C4630419ED717AC79FCF9A909785B@BL2PRD0410MB363.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A906E74E@CH1PRD0410MB369.namprd04.prod.outlook.com> <4F885680.5090801@mitre.org> <59E470B10C4630419ED717AC79FCF9A9090519@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A909785B@BL2PRD0410MB363.namprd04.prod.outlook.com> From: Brian Campbell Date: Fri, 20 Apr 2012 06:26:54 -0600 Message-ID: To: Lewis Adam-CAL022 Content-Type: multipart/alternative; boundary=bcaec54ee7562992b004be1b69f2 X-Gm-Message-State: ALoCoQksbio8L5c+I07/udTTL7mMjqMS2XhyayqLPHVC5Vg8lnHSCYs8gt6gcxhGmmG6mtYlGAbl Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Fri, 20 Apr 2012 12:27:27 -0000 --bcaec54ee7562992b004be1b69f2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You're right, resource owner credentials is specifically for username and password. If by RSA you mean a one time password from a hard token, you might be able to kind of shove it into a resource owner credentials flow. But I don't think that was really the intent. If you mean RSA signatures, then it doesn't really work. In general stronger forms of user authentication for direct client to AS communications are allowed for by the extensibility of the grant type mechanism: http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.5but that does require an extension spec or a proprietary implementation. There is work underway to standardize some assertion/token grants with this abstract definition http://tools.ietf.org/html/draft-ietf-oauth-assertionsand these more concrete definitions for SAML and JWT respectively http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer and http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer Neither of those directly address the question of other forms of stronger authentication directly with the AS. However some from of stronger authn could have been used to acquire the SAML or JWT - maybe an X509 token sent to an STS. Admittedly that just kind of pushes the problem around and there's some chicken and egg going on here. On Thu, Apr 19, 2012 at 4:25 PM, Lewis Adam-CAL022 < Adam.Lewis@motorolasolutions.com> wrote: > Hi Brian,**** > > ** ** > > I was also looking at the resource owner credentials flow, but it seems > limited to username & password =85 it=92s not clear that it would work wi= th > stronger authentication methods such as RSA. Thoughts?**** > > ** ** > > adam**** > > ** ** > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Thursday, April 19, 2012 5:08 PM > *To:* Lewis Adam-CAL022 > *Cc:* Justin Richer; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token**** > > ** ** > > A browser isn't required. The browser based flows are pretty common with > OAuth but they are certainly not the only way to get a token. > > The resource owner credentials and client credentials grant types are bot= h > involve only direct communication between the client and the AS. And ther= e > are also the SAML and JWT grants that allow a client to get an access tok= en > directly from an AS without a browser being involved.**** > > On Thu, Apr 19, 2012 at 3:37 PM, Lewis Adam-CAL022 < > Adam.Lewis@motorolasolutions.com> wrote:**** > > Hi Justin,**** > > **** > > There is one thing I have not understood about the whole external browser > vs. embedded browser guidance =85 and that is, why is **any** browser > needed? Java for example has an HTTP library, and OAuth is RESTful. So > why is it necessary to require the web browser at all, whether external o= r > embedded? Why can=92t my native client make RESTful API calls to the AS = and > RS natively?**** > > **** > > Tx!**** > > adam**** > > **** > > *From:* Justin Richer [mailto:jricher@mitre.org] > *Sent:* Friday, April 13, 2012 11:38 AM > *To:* Lewis Adam-CAL022 > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token**** > > **** > > If the mobile device has a web browser (such as a smart phone), then this > is pretty easy, and you've got a couple of options. > > One of the best options when the token is on behalf of an end user is, in > my opinion, to use the authorization code flow like this: First, register > what's called a "public client" with your server -- so you'll get an ID b= ut > not a client secret. With that client ID, register a custom-scheme callba= ck > URI, like "myapp://oauthcallback", and register your app on the device as > the handler for "myapp". > > In your application, to start things off, you fire off a web browser to > the authorization server's authorization endpoint. The user logs in to th= e > authorization server through the web browser, approves this copy of your > app, and gets redirected to "myapp://oauthcallback?code=3Dbasdf132". Your= app > grabs the "myapp://" url and plucks the authorization code off the end of > it. Your app then takes that code and sends it in the background to the > token endpoint to exchange for a token. > > Some key points: > > 1) You need to have access to a web browser on the platform, and it's > considered best practice to push the user to the external browser > application on the platform instead of embedding one. There are a couple > paragraphs in the spec's security considerations section that talk about > this. > 2) Your app is "public" because you can't publish it with a secret at > configuration time. It can, however, keep the tokens secret at runtime. > 3) You need to be very careful with how you store the tokens on the devic= e > -- they need to be in a trusted space where other apps on the device can'= t > sniff them out. > 4) Another app can try to register "myapp://" and intercept your code on > the way through, so make sure your codes are all one time use and short > lived. > > None of this is just theoretically possible, people are doing it today. > What libraries and stuff you'd be after depends wholly on your platform > (both server and client side). > > -- Justin > > On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote: **** > > Hi all,**** > > **** > > I=92ve been talking to some of you off line about this already, but I nee= d > some help in terms of implementation. I would like to use OAuth as a mea= ns > to get either a JWT or SAML token to a client running on a handheld > device. This is something that I=92m looking to prototype (as part of a > larger project) beginning this week. So, it is important to me to > understand the divide between what is theoretically possible and what is > actually possible.**** > > **** > > Anybody aware of any implementations out there, either vendor or open > source, that I can use for this?**** > > **** > > Tx! > adam**** > > > > **** > > _______________________________________________**** > > 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**** > > ** ** > --bcaec54ee7562992b004be1b69f2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You're right, resource owner credentials is specifically for username a= nd password. If by RSA you mean a one time password from a hard token, you = might be able to kind of shove it into a resource owner credentials flow.= =A0 But I don't think that was really the intent. If you mean RSA signa= tures, then it doesn't really work.

In general stronger forms of user authentication for direct client to A= S communications are allowed for by the extensibility of the grant type mec= hanism: http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.5 bu= t that does require an extension spec or a proprietary implementation.=A0 <= br>
There is work underway to standardize some assertion/token grants with = this abstract definition http://tools.ietf.org/html/draft-ietf-oauth-assertions= and these more concrete definitions for SAML and JWT respectively http://tools.= ietf.org/html/draft-ietf-oauth-saml2-bearer and http://tools.ietf.org/html/dra= ft-jones-oauth-jwt-bearer

Neither of those directly address the question of other forms of strong= er authentication directly with the AS. However some from of stronger authn= could have been used to acquire the SAML or JWT - maybe an X509 token sent= to an STS. Admittedly that just kind of pushes the problem around and ther= e's some chicken and egg going on here.






On Thu, Apr 19, 2012 at = 4:25 PM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> w= rote:

Hi Brian,

=A0

I was also looking at the resource owner cre= dentials flow, but it seems limited to username & password =85 it=92s n= ot clear that it would work with stronger authentication methods such as RSA.=A0 Thoughts?

=A0

adam

=A0

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, April 19, 2012 5:08 PM
To: Lewis Adam-CAL022
Cc: Justin Richer; oauth@ietf.org


Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

=A0

A browser isn't r= equired. The browser based flows are pretty common with OAuth but they are = certainly not the only way to get a token.

The resource owner credentials and client credentials grant types are both = involve only direct communication between the client and the AS. And there = are also the SAML and JWT grants that allow a client to get an access token= directly from an AS without a browser being involved.

On Thu, Apr 19, 2012 at 3:37 PM, Lewis Adam-CAL022 &= lt;Ad= am.Lewis@motorolasolutions.com> wrote:

Hi Justin,=

=A0=

There is one thing I hav= e not understood about the whole external browser vs. embedded browser guid= ance =85 and that is, why is *any* browser needed?=A0 Java for example has an HTTP library, and OAuth is RESTful.=A0 So why is i= t necessary to require the web browser at all, whether external or embedded= ?=A0 Why can=92t my native client make RESTful API calls to the AS and RS n= atively?

=A0=

Tx!=

adam

=A0=

From: Justin R= icher [mailto:jriche= r@mitre.org]
Sent: Friday, April 13, 2012 11:38 AM
To: Lewis Adam-CAL022
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

=A0

If the mobile device has a web browser (such as a sm= art phone), then this is pretty easy, and you've got a couple of option= s.

One of the best options when the token is on behalf of an end user is, in m= y opinion, to use the authorization code flow like this: First, register wh= at's called a "public client" with your server -- so you'= ll get an ID but not a client secret. With that client ID, register a custom-scheme callback URI, like "myapp://oauthcallbac= k", and register your app on the device as the handler for "myapp= ".

In your application, to start things off, you fire off a web browser to the= authorization server's authorization endpoint. The user logs in to the= authorization server through the web browser, approves this copy of your a= pp, and gets redirected to "myapp://oauthcallback?code=3Dbasdf132"= ;. Your app grabs the "myapp://" url and plucks the authorization c= ode off the end of it. Your app then takes that code and sends it in the ba= ckground to the token endpoint to exchange for a token.

Some key points:

1) You need to have access to a web browser on the platform, and it's c= onsidered best practice to push the user to the external browser applicatio= n on the platform instead of embedding one. There are a couple paragraphs i= n the spec's security considerations section that talk about this.
2) Your app is "public" because you can't publish it with a s= ecret at configuration time. It can, however, keep the tokens secret at run= time.
3) You need to be very careful with how you store the tokens on the device = -- they need to be in a trusted space where other apps on the device can= 9;t sniff them out.
4) Another app can try to register "myapp://" and intercept your = code on the way through, so make sure your codes are all one time use and s= hort lived.

None of this is just theoretically possible, people are doing it today. Wha= t libraries and stuff you'd be after depends wholly on your platform (b= oth server and client side).

=A0-- Justin

On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote:

Hi all,

=A0

I=92ve been talking to some of you off line about th= is already, but I need some help in terms of implementation.=A0 I would lik= e to use OAuth as a means to get either a JWT or SAML token to a client running on a handheld device.=A0 This is something that = I=92m looking to prototype (as part of a larger project) beginning this wee= k.=A0 So, it is important to me to understand the divide between what is th= eoretically possible and what is actually possible.

=A0

Anybody aware of any implementations out there, eith= er vendor or open source, that I can use for this?

=A0

Tx!
adam



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth

=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0


--bcaec54ee7562992b004be1b69f2-- From paul.madsen@gmail.com Fri Apr 20 05:57:44 2012 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 8392A21F8702 for ; Fri, 20 Apr 2012 05:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvwYTfd0MijU for ; Fri, 20 Apr 2012 05:57:43 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F085321F86E0 for ; Fri, 20 Apr 2012 05:57:42 -0700 (PDT) Received: by iazz13 with SMTP id z13so16342892iaz.31 for ; Fri, 20 Apr 2012 05:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=06ScMnl8TmPQ2CedjGGfb6lr3epUNNVHnm232+wK0AI=; b=Bs4PuuwQomL+Yy7mAuD4eUZGX1gvjqSljOgpHjnILUE1mDnTTGUcipkFfZQpwC+z4V vVtRWEDD6cYPP9/RNFxB4UV+MtT+vMR83oBV9Q5mO1F1bS+rvIWt88ewx4dgt8qJJpv8 cakCqm5LqZ4hAxp8PFS7nQLGf+gBihLfKplZ0PKE9n/jrZve9hq/V8AksbSYWusCUmuw BRVQ22AGm5PP+zoHB1DeDegEXZhUCnTOIh3kqZ96EZ24nHeZUC4heJoqumWNPCV+rjRj XUP86Y3pcIIZVliZeG/yPQmhOvW5oMR1i0U1Bv+5bSLdglqgwR5qPgiuRHBvCnSwEDAF eQuQ== Received: by 10.50.187.169 with SMTP id ft9mr5927989igc.59.1334926662561; Fri, 20 Apr 2012 05:57:42 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [99.224.20.155]) by mx.google.com with ESMTPS id m4sm8298665igw.1.2012.04.20.05.57.39 (version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 05:57:40 -0700 (PDT) Message-ID: <4F915D42.9030903@gmail.com> Date: Fri, 20 Apr 2012 08:57:38 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <5jrlua1y80mdxtvpmygf5tp1.1334872982862@email.android.com> <59E470B10C4630419ED717AC79FCF9A9097843@BL2PRD0410MB363.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9097843@BL2PRD0410MB363.namprd04.prod.outlook.com> Content-Type: multipart/mixed; boundary="------------020900090709080206050101" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Fri, 20 Apr 2012 12:57:44 -0000 This is a multi-part message in MIME format. --------------020900090709080206050101 Content-Type: multipart/alternative; boundary="------------070609070007040602000708" --------------070609070007040602000708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Adam, FWIW I tried to tease out some of the choices & dependencies around OAuth for native apps in the enclosed deck YMMV paul On 4/19/12 6:11 PM, Lewis Adam-CAL022 wrote: > > Hi Paul, > > So by saying ‘more easily’ then there is nothing really inherently > preventing a native implementation from making the HTTP calls to the > AS directly, right? > > My use cases are a bit atypical from the web service driven models > that you guys are solving, but I think the technology should still > fit. The RS that my native client is talking to is **not** a web > service (I realize I’m not outside the bounds of OAuth-proper here). > But it’s easy enough for me to use OAuth to get an access-token and > include that in my message between my native client and my (non-web > service) RS. My RS can still introspect it against an OAuth STS. > > These native apps I’m speaking of, I’m attempting to retrofit with > OAuth, and today they already have native interfaces for accepting a > user’s logon and credentials … to pop a web browser would not be > intuitive to my customer base. > > I don’t see any reason I can’t implement this native within my client, > just want to be sure since the browser trick is such a prominent > trend, I want to be sure that there’s no gotcha I haven’t thought of. > > Tx! > adam > > *From:*Paul Madsen [mailto:paul.madsen@gmail.com] > *Sent:* Thursday, April 19, 2012 5:03 PM > *To:* Lewis Adam-CAL022; jricher@mitre.org > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token > > Using the browser as part of the AS interaction allows you to more > easily collect the users consent. > > Once you get the tokens based on that consent, everything is 'RESTful' > > > > > -------- Original message -------- > Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token > From: Lewis Adam-CAL022 > To: Justin Richer > CC: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token > > Hi Justin, > > There is one thing I have not understood about the whole external > browser vs. embedded browser guidance … and that is, why is **any** > browser needed? Java for example has an HTTP library, and OAuth is > RESTful. So why is it necessary to require the web browser at all, > whether external or embedded? Why can’t my native client make RESTful > API calls to the AS and RS natively? > > Tx! > > adam > > *From:*Justin Richer [mailto:jricher@mitre.org] > *Sent:* Friday, April 13, 2012 11:38 AM > *To:* Lewis Adam-CAL022 > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token > > If the mobile device has a web browser (such as a smart phone), then > this is pretty easy, and you've got a couple of options. > > One of the best options when the token is on behalf of an end user is, > in my opinion, to use the authorization code flow like this: First, > register what's called a "public client" with your server -- so you'll > get an ID but not a client secret. With that client ID, register a > custom-scheme callback URI, like "myapp://oauthcallback", and register > your app on the device as the handler for "myapp". > > In your application, to start things off, you fire off a web browser > to the authorization server's authorization endpoint. The user logs in > to the authorization server through the web browser, approves this > copy of your app, and gets redirected to > "myapp://oauthcallback?code=basdf132". Your app grabs the "myapp://" > url and plucks the authorization code off the end of it. Your app then > takes that code and sends it in the background to the token endpoint > to exchange for a token. > > Some key points: > > 1) You need to have access to a web browser on the platform, and it's > considered best practice to push the user to the external browser > application on the platform instead of embedding one. There are a > couple paragraphs in the spec's security considerations section that > talk about this. > 2) Your app is "public" because you can't publish it with a secret at > configuration time. It can, however, keep the tokens secret at runtime. > 3) You need to be very careful with how you store the tokens on the > device -- they need to be in a trusted space where other apps on the > device can't sniff them out. > 4) Another app can try to register "myapp://" and intercept your code > on the way through, so make sure your codes are all one time use and > short lived. > > None of this is just theoretically possible, people are doing it > today. What libraries and stuff you'd be after depends wholly on your > platform (both server and client side). > > -- Justin > > On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote: > > Hi all, > > I’ve been talking to some of you off line about this already, but I > need some help in terms of implementation. I would like to use OAuth > as a means to get either a JWT or SAML token to a client running on a > handheld device. This is something that I’m looking to prototype (as > part of a larger project) beginning this week. So, it is important to > me to understand the divide between what is theoretically possible and > what is actually possible. > > Anybody aware of any implementations out there, either vendor or open > source, that I can use for this? > > Tx! > adam > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------070609070007040602000708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Adam, FWIW I tried to tease out some of the choices & dependencies around OAuth for native apps in the enclosed deck


YMMV

paul

On 4/19/12 6:11 PM, Lewis Adam-CAL022 wrote:

Hi Paul,

 

So by saying ‘more easily’ then there is nothing really inherently preventing a native implementation from making the HTTP calls to the AS directly, right?

 

My use cases are a bit atypical from the web service driven models that you guys are solving, but I think the technology should still fit.  The RS that my native client is talking to is *not* a web service (I realize I’m not outside the bounds of OAuth-proper here).  But it’s easy enough for me to use OAuth to get an access-token and include that in my message between my native client and my (non-web service) RS.  My RS can still introspect it against an OAuth STS.

 

These native apps I’m speaking of, I’m attempting to retrofit with OAuth, and today they already have native interfaces for accepting a user’s logon and credentials … to pop a web browser would not be intuitive to my customer base. 

 

I don’t see any reason I can’t implement this native within my client, just want to be sure since the browser trick is such a prominent trend, I want to be sure that there’s no gotcha I haven’t thought of. 

 

Tx!
adam

 

From: Paul Madsen [mailto:paul.madsen@gmail.com]
Sent: Thursday, April 19, 2012 5:03 PM
To: Lewis Adam-CAL022; jricher@mitre.org
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

 

Using the browser as part of the AS interaction allows you to more easily collect the users consent. 

 

Once you get the tokens based on that consent, everything is 'RESTful'




-------- Original message --------
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token
From: Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com>
To: Justin Richer <jricher@mitre.org>
CC: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

Hi Justin,

 

There is one thing I have not understood about the whole external browser vs. embedded browser guidance … and that is, why is *any* browser needed?  Java for example has an HTTP library, and OAuth is RESTful.  So why is it necessary to require the web browser at all, whether external or embedded?  Why can’t my native client make RESTful API calls to the AS and RS natively?

 

Tx!

adam

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, April 13, 2012 11:38 AM
To: Lewis Adam-CAL022
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

 

If the mobile device has a web browser (such as a smart phone), then this is pretty easy, and you've got a couple of options.

One of the best options when the token is on behalf of an end user is, in my opinion, to use the authorization code flow like this: First, register what's called a "public client" with your server -- so you'll get an ID but not a client secret. With that client ID, register a custom-scheme callback URI, like "myapp://oauthcallback", and register your app on the device as the handler for "myapp".

In your application, to start things off, you fire off a web browser to the authorization server's authorization endpoint. The user logs in to the authorization server through the web browser, approves this copy of your app, and gets redirected to "myapp://oauthcallback?code=basdf132". Your app grabs the "myapp://" url and plucks the authorization code off the end of it. Your app then takes that code and sends it in the background to the token endpoint to exchange for a token.

Some key points:

1) You need to have access to a web browser on the platform, and it's considered best practice to push the user to the external browser application on the platform instead of embedding one. There are a couple paragraphs in the spec's security considerations section that talk about this.
2) Your app is "public" because you can't publish it with a secret at configuration time. It can, however, keep the tokens secret at runtime.
3) You need to be very careful with how you store the tokens on the device -- they need to be in a trusted space where other apps on the device can't sniff them out.
4) Another app can try to register "myapp://" and intercept your code on the way through, so make sure your codes are all one time use and short lived.

None of this is just theoretically possible, people are doing it today. What libraries and stuff you'd be after depends wholly on your platform (both server and client side).

 -- Justin

On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote:

Hi all,

 

I’ve been talking to some of you off line about this already, but I need some help in terms of implementation.  I would like to use OAuth as a means to get either a JWT or SAML token to a client running on a handheld device.  This is something that I’m looking to prototype (as part of a larger project) beginning this week.  So, it is important to me to understand the divide between what is theoretically possible and what is actually possible.

 

Anybody aware of any implementations out there, either vendor or open source, that I can use for this?

 

Tx!
adam





_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

--------------070609070007040602000708-- --------------020900090709080206050101 Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="mobile-oauth-decision-04.pptx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mobile-oauth-decision-04.pptx" UEsDBBQABgAIAAAAIQAedgXXWAIAAOkSAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEmMlu2zAQhu8F+g4Cr4VFO22zwXYOXU5d AiR9AEYa22wlkiBpN377jjZDFWxt8SAXG5LMmY8/h8Pfmt89p0mwA+ukVgs2C6csABXpWKr1 gv16/Dq5ZoHzQsUi0QoWbA+O3S3fvpk/7g24AEcrt2Ab780t5y7aQCpcqA0ofLLSNhUeL+2a GxH9EWvgF9PpJY+08qD8xGcx2HL+GVZim/jgyzPeLkgsJI4Fn4ofZrkWTBiTyEh4JOU7FTey TMoMIY7Mf+M20rh3iMH4cv4Tp2hlDMG9sP6HSDEcN8Zzl+DNb2Kvt97VL2ZhNnBQfr1ayQhi HW1TnFtoLDj8zlHSJKwl6sVU0sxoQCqEI8K3z7uPnCX6DYmELeS/DawbSybTrObyBy1F4MVT Ag9+n4A7N3MtdEU+tBSvz800shSvSDjGqnJJQlN0gl5MZZV/JOHoRXCsbV2Q4AyQ5btwHk+T opcWFzQtrIg9VqgPr61TqdB7Eo6xqsymJDjd5YOn5r3VxqEzsDCcoTr6s9ETg4HAegmth/8h I7qK4QkbZz1kviWGuGfuNuPx6hu4LEyaTdurMCsCGikqhCPW50mqhn/osJyNMmhYPmMl2lz7 AN6jm3adNrSaN80mrOZ9yn7sJPzN9+CLd0NDhkPgLoKaLymlKBoHjZHsbkqHbVrS0BixLlXq ap57af6LnQqpumBOLRGNNxy+RDSucKwqNN5wuCo0ZmesKkR/afvJ4vEFBfD88+UnXB6mS4Zs j5H01UPgLoJTm5bGe/Zbh5yp7Ku05zzPX1Qt/wEAAP//AwBQSwMEFAAGAAgAAAAhAKPsgiYN AQAA4gIAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACsksFOwzAMhu9IvEPk+5puIITQ0l0Q0m4IlQcwidsG2iRKPLS9PWGHlUqjmgTH2PGf78/v 9WY/9OKTYrLeKVgWJQhy2hvrWgWv9dPiHkRidAZ770jBgRJsquur9Qv1yHkodTYkkVVcUtAx hwcpk+5owFT4QC53Gh8H5HyMrQyoP7AluSrLOxl/akA10RRboyBuzQ2I+hDyy3/RlgMxGmSU 2kdahJjJItvsRdQYW2IFxuvnXE7HG0WmBnke6PZyIN80VtOj17uBHJ/xLGnP5AyZeSQMYY5o +Z9EU+bxf0JgGSKlbOSY+xzQ6nKg3/dhzIy73fDm0PYjzSmtU694D9R+ZyYnm1l9AQAA//8D AFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1 LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1O fXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457 pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTz jwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1 Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc4SPwQrCMBBE 74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E6 32m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpU RPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5By fue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/ YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokY Ds1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0Hwxxdlq SGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA //8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGU2LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd 5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvo c457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5 juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAh AEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc4SPwQrC MBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQ N8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRc ZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuoo a5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAA cHB0L3NsaWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyII nkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGT hokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0Hwx xdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sP AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMv c2xpZGU3LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wg eJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQ PGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesM HYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgA AAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlOC54bWwucmVsc4SP wQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1 rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cN acRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPB Yuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAh AAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEyLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhI Uy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7o LQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirN GdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZW X3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACEAAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlMTEueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK /XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC 3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+ zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQU AAYACAAAACEAS/U97L8AAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMC54bWwu cmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4 UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQi yxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOz dMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAA ADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTkueG1sLnJlbHOEj8EKwjAQRO+C/xD2 blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9O qx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7U pqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI 8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEA4WKGpoUBAAA1CgAAHwAIAXBwdC9fcmVs cy9wcmVzZW50YXRpb24ueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAC8ls1uwjAMgO+T9g5V7msa/pkoXKZJHCZNgz1AaE2J1iZRkrHx 9osKg1IN7xL1UslO63xy4k+dLb6rMtqDsULJlLA4IRHITOVCFil5Xz8/TEhkHZc5L5WElBzA ksX8/m72BiV3/iO7E9pGvoq0Kdk5px8ptdkOKm5jpUH6la0yFXc+NAXVPPvgBdBekoyoadYg 86ua0TJPiVnmjJFofdB+6/+Lq+1WZPCkss8KpPtjD2pLkYMvyE0BLiV1aI9ZlsSeldAbGL2u MBiK0e8Ko4diDEJiaCOkA7MC5/y1s5fjaS3QVszijZA3D2wYFhHsq1H6Cu6UQhs1CkmxF/DV ojinUIpxSArnh7sxQ3VI6yd+db1Jwg2y45sSVu5Qeh+dx7mRRNsREqRWyAu3/gJfQBrJk12O b6AN6swwWG+68guql6B2QZTfxzoR1B8IxACDCKoPBGKIQQS1BwIxwiCC2gOBGGMQ0+DmaDnj ZIsJBsH8P1o4kSKtmP5S0KufvfkPAAAA//8DAFBLAwQUAAYACAAAACEAYm2TLuwCAACxDgAA FAAAAHBwdC9wcmVzZW50YXRpb24ueG1s7JffbtowFMbvJ+0dIl9uovlDSEJEqLZOlSp1Ehrt AxjHQFTbiWwngz39jk0Al2xSHyB3iT+fzz4/Hx/C4v7AmddRqapaFCi8C5BHBanLSuwK9Pry OMmQpzQWJWa1oAU6UoXul58/LZq8kVRRobGGUA9shMpxgfZaN7nvK7KnHKu7uqECtG0tOdbw Knd+KfFvsOfMj4Ig8TmuBOrj5Ufi6+22IvRHTVoOy59MJGV2H2pfNersxslH7DiWb20zITVv wGJTsUofrenFpitQK0XepzThFZG1qrfaxOQck7zjDHmc5E87UUu8YcCJd3ZkZRjJjn7TWlab VlNlpPzL2bv5yA5d0O+pKdzRdbtRVD/WQoN3iDzc6voBkoGV1aoiuoWHAgVoCUemWPkTK03l U/ms9M2IV5UFisI4jbNpkkbIk7kZgbkh8pcL/z/hrtVTeTJJEyc6MtE2+CwnsSNPh/LMkeOh 7JrPhvLciU4GcgoVfkksHcpA8CJnQ9nFMh/KUyc6DIa6m3hosb4Dk7qZh/8AB7fxsrvQkjsd i3sI6z8eORRoHsZxEEC25FigJJtl9kUfG6hORSSlIj707EUNhdmHXWaasLOHPcCSbnHL9As9 6LU+Mrpc4BzGVivZP/1aSY9h0ziomLyuTfa+O4V1LGxgDty4Z1ORHmY7aDpwd8DmBW/WfwoU z1LoCpClZnYKxc/iu3yzlW2uuOhfYcoeloI+smoF0UZ3dqHAKYSEkfdGpelrxtPoqmZV+Vgx Zl9Mj6IPTHodhtX04VTnN7Psqp7htsUE2H3lYsK0SQ7nFN8IFJ8Eom4Eoq44gJMl0/MwRvAY XdGcIYx8DJSez/TK51SWY/10zEDp+cRXPuE0DRNT/WMBGSo9oJkDKIsy2x5GQIZKDyi5Aoqi DAporCDoy4ZKDyh1AKXx1P5QjRVkqPSAsisgQwe+P8Ye1DFDpQc0dwAls3Rs0vbTx1CxfzCG n5jweev+/Vn+BQAA//8DAFBLAwQUAAYACAAAACEA6J6dFjMCAAD5BAAAFQAAAHBwdC9zbGlk ZXMvc2xpZGUxLnhtbKyU22obMRCG7wt9B6HLgrOOC6UIr0OatKXQJqZ2HmCslb0iOiGNt963 70jrdWiTgAu90eow82v+T9LOrw7WsE7FpL2r+eXFlDPlpG+029X8Yf1l8pGzhOAaMN6pmvcq 8avF2zfzIJJpGGW7JKDmLWIQVZVkqyykCx+Uo7WtjxaQhnFXNRF+kao11Ww6/VBZ0I4f8+M5 +X671VLderm3yuEgEpUBpMpTq0Ma1aw8R85CfNyHifQ2kMRGG419ET3JdDXfRyeOliZWy+iT 32LOERak6KzhzErxbed8hI0hPLYrM8uokoqdukaMerNHlfKSeDdqh3MqDFnEYTH4B7UFwZcr 0+RvCuuoVO657msMq7CMZfmuW0amGzpSzhxYKo1Xx4VjWBk6CqNO9Vf6blQCcdhGu5iDIPzs UHO6H31uKQmEOiCTw6R8mpXt/Quxsv38QnQ1bkAVnDbNrgZHz+3MRjtrjUaxy5OrIRQo9buX j4k5Tz6z/cGevOtGsew5y4eWYR+IDGapY9ywWHiM8YmYFlh4+OSbPhvf0LdMgjAJV9gbVYBQ 2SBInBrCbyA/IuUmD6usDgIXtyoY39MzYPfXe2wZPRA6HtSdYhBCmhMPpOMoItSSHpUy7kvd AczreN6PeG68Q7o8bGlAqtabRkU2y1XQ1RlR/CMs3dBRjzz/AyflmiVE+Pmc1GvOC4DhvlN3 fALSxB8Q7rvCnX4+qOJNmQrEmRzn0KeQrEFP5zcAAAD//wMAUEsDBBQABgAIAAAAIQCbtX0V RAUAAGUaAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTgueG1s7FnNcts2EL53pu+A4bEzjgj+k2PZ k7pxxp3W9tjKA0AkJHEMAiwAyVJOeYee+np5ki7AH1uyUimVekjji0RRu0vufvuP0/NlxdCC SlUKPnTwG9dBlOeiKPl06HwYXZ4kDlKa8IIwwenQWVHlnJ/9+MNpnSlWIODmKiNDZ6Z1nQ0G Kp/Riqg3oqYc/psIWRENP+V0UEjyCFIrNvBcNxpUpOROyy/34ReTSZnTX0Q+ryjXjRBJGdHw 5mpW1qqTVuX7iKuIfJjXJ7moahAxLlmpV1ZoL2YxdOaSZ61KJ1WZS6HERBuerCJ5tqiYg6o8 u5pyIcmYgXmqhb1zK6mickHfai3L8VxTZf7Kfupk1/u8YW2EcG0VXLPaGRg/v2eF+Vb1SFJq rvjivazv61tp/75e3EpUFgCpgzip4NWcQftHS2Z/ciCDi8EG+7STRLLlRFZnpyQD86Pl0AH/ WJlPYCIZXWqUNzfzp7v57GYLbT57t4V60D0A3qB/qNGq0eilOkGnzs2CMOT3ShnKFxp17Mpa pXtUrwtOE9+PY6sRxl4Q4XBdryCMPS/wHGS0CwLXS93UUPRvTbJaKv2eigqZi6FDGQNPpI6x Dln8pnRD3VGZ21xcloxZ+zFu/jbqNqgpvWKAJckYv6MTgA9si60s64T0gkkEag8dkufgGbh9 F0tt2CYguGf0dzO29IaVTiY01z2zt5u557BPFvyJuSohHrYJYP0rTxr6RvtGa2sHA/uXwQ87 8EfgeT+LJQqMBSAYrhcGaqSXcNOYzN597ts7PCHFqedDpgOY/ThIQ88KfnJw7EYB9tPGEfwo 9X3vn/1AgjGtBXY5wTP0zdsXK2PNMXyDOo+SQKJQf8yJpA6Sml0IwN5tLFu/nWvwpNbBGg7D y5S+Nwa1DgZhRDJpP0AeIyapU37y4b6RIVhZGGc0BEpOx71/uW7iujbIwdXVExn8ksZVSabP LuZKi8rEgrYRAbfhGp4IKnWq7IFptImpjcEjYIrdGEctqIEXYy+MDGavoFqcvgSqEA8lPRhU yKlN0ekC1Zr+GKDGYQTA2kgNYi8JXkHdHamjUrPDMYX0uI5pfKTk63lJgtsynATxiyq8lnyj IPL9rvB1vUlXXtsi/B0kX+ilqOSEbYlUm4P/s6w/luIRWtstz/26tA+1dN2bkiN5U4Rj7If+ a4boesV9avndDbqQtFAHw4phPljH1TbMR8j8kR9HSQjTjGnFPTeKv/ce7fISWrQdPdpVVbMy L/XhuPZjZFfRAenj9N5R7PqB1wTs9uY79LD/2nwbDPvmG5r/2UcEe5rD6zqG+XY9ZHE7QB08 VvkxTEowMtuYjRNo1zY6cB+7UPubseq1stux6l01pkVBiy0h+21UdgyhvOFPdlg+Qg0IQxym xl+hBqRJhDf3Nfi5P72O6dafrjgr+RGyRL946wvA+vLt3y9fnmcJL8VJ6NnJ4tmgDlu4yAW3 Mmu4BBJKagkgH36rAwBSH4eOF0D5RuN2X2XWKNeUFkjSCSx+Z+dbEsDXtdgQHZuBeKx9GTTY KW6bsQh7OAo2MnuAoaxHMDIayP4XmX0NqF9h91XCcYTdzaPPn/5EekZR2XZbaCoJ16gQVPHP n/7SSM3rWkjdQYu0eKB8v2bbbtCaFT9cdlv/nMnfSX2zsKs4OG+BYRB2d3CrhhMWaMsM6RMJ 7ONK2MlOzapUc1hKm4uaADOQjXh3TFDM4Rym5AWdlLzUZuNI4eRHwlabUzghAmeCdmO0quEs QVd3QmhTzOFJVhJ8t6LNVfs4uIRDorO/AQAA//8DAFBLAwQUAAYACAAAACEAzPJnApUFAAAr GwAAFQAAAHBwdC9zbGlkZXMvc2xpZGU5LnhtbOxZ727bNhD/PmDvQOjLgGGpRf2XUKfosqbo sDVBkz4ALVE2UYrUSNqN+6nvsDfck+xI/YmdOItbe8CGNB8Shbo78e53f3jH5y9uGo5WVGkm xdTDz3wPUVHKion51Ht/fX6SeUgbIirCpaBTb0219+L0+++et4XmFQJuoQsy9RbGtMVkossF bYh+Jlsq4F0tVUMM/Kvmk0qRjyC14ZPA95NJQ5jwen61D7+sa1bSX2S5bKgwnRBFOTGwc71g rR6kNeU+4hqiPizbk1I2LYiYMc7M2gkdxaym3lKJolfppGGlklrWxvIUDSmLVcM91JTFm7mQ isw4mKdZuZVLRTVVK/rSGMVmS0O1fVX8OMhu99lha4UI4xTcstopGL+84pX9q9trRal9EqvX qr1qL5V7/XZ1qRCrAFIPCdLA1rxJ/6Inc/8KIIOHyR32+SCJFDe1ak6fkwLMj26mHvjH2v4G JlLQG4PKbrG8XS0XFztoy8WrHdST4QOwg/GjVqtOo/vqRIM6FyvCUTgqZSnvaTSwa2eV4VOj LjjPwjBNnUYYB1GC4229ojgNgijwkNUuivwg93NLMe6aFK3S5jWVDbIPU49yDp5IPWsdsvpN m456oLLLQp4zzp39uLCvrbodatqsOWBJCi7e0RrgA9tiJ8s5IT3jCoHaU4+UJXgG7vfiqC1b DYJHxvBxxp7estK6pqUZmYPHmUcO92UpbpkbBvGwSwAft1x39J32ndbODhb2h8GPB/CvwfN+ ljcoshaAYHi7slAjcwOL1mRuddO3H/GEHOdBCJkOYA7TKI8DJ/jWwbGfRDjMO0cIkzwMg3/2 AwXGdBZ4zAk20Le7r9bWmjP4C+p8VAQShf5jSRT1kDL8TAL2fmfZ9uXSgCf1DtZxWF6uzZU1 qHMwCCNSKPcL5HFikzoVJ++vOhmSs8o6oyXQaj4b/ev83IefXkV9SwaOr6yrksKcni21kY2N BeMiApbhGb4IKg2q7IFpchdTF4NHwBT7KU56UKMgxUGcWIWeLqi+nz0OqpQfGD0YVMipXdEZ AtWZ/higpnECwLpIjdIgi76B+jio18zwwzGF9LiNadql2YOTbxBkGe7LcBal96rwVvJNoiQM h8I3nE2G8toX4SeQfOEsRZUgfEekuhz8r2X9mZIf4Wi747tflvahlm57U3Ykb0pwisM4/JYh hrPiPmn/3QU6U7TSB8OKoT/YxtUdmI+Q+ZMwTbIYuhl7FA/8JH3qZ7R9cH3TtJyVzByO69hG DhUdkD7O2TtJ/TAKuoDdffiOAxw+ocP3PsDC4X/xCcGc5vC6jqG/3Q5Z3DdQB1f2MIVOCVpm F7NpBse1OyfwEPtQ+7u26glU9n2QfdXMaFXRakfIfn1l3+fDx6rsGEL5jj+5ZvkINSCOcZxb f4UakGcJvjuvwZv+9ATa9H1gfSM4E0fIEuPgbSwA28O3rx++bGaJIMdZHLjOYqNRhylc4oNb 2TFcBgkldwQPT+H+8w0A0p+mXhDBiAXN+nmVHaNcLhhMssUcKaY/vNiRAb7sjA3hcTcSjzUw wxt9eJzmOE6dN9xiBofwLImgUbeYwXAN6oDN/f9nzDaR+hWGXwzuI9xwHv31+U/EamQWFJG2 RRXT3dgfbiZQuSBCUI5KIn4waAvTB5q0ziUQ23CMOYwAiTCUfoEAN+sypwQpOV92G+v2UHLC GrfZ0o3wUDdc/gk1ZI04JRUyEjppWlMFV0EUwSUOon1VQn2VQLDG9s8sbg7YXVTA43B3UXL1 O2kvVm6gCLdG0NLCBBKWWogB6yxAeksCU0UGk+W5HfgaAaN1+9ASYAayazFcdlRLuE1ioqI1 E8zYuSmF+ysFs3lB4Z4LIgIOTdfrFm5ETPNOSuPcspdk46sTbZ/6z8EjXHWd/g0AAP//AwBQ SwMEFAAGAAgAAAAhALZ2NVF+BQAAyRoAABYAAABwcHQvc2xpZGVzL3NsaWRlMTAueG1s7Flt b9s2EP4+YP+B0MdhiUXqXYhTdFlTZC9NkaQ/gJaoWChFaiTt2P31O1IvjlN3cWsP2JAmgE1L d0fePce74/Hs1arhaMmUrqWYevjU9xAThSxrcT/1PtxdnqQe0oaKknIp2NRbM+29Ov/xh7M2 17xEwC10Tqfe3Jg2n0x0MWcN1aeyZQLeVVI11MBPdT8pFX0AqQ2fEN+PJw2thdfzq334ZVXV BftVFouGCdMJUYxTAyvX87rVg7Sm2EdcQ9XHRXtSyKYFEbOa12bthI5illNvoUTeq3TS1IWS WlbG8uQNLfJlwz3UFPnVvZCKzjiYp1m6J+8V00wt2WtjVD1bGKbtq/ynQXa7zwpbK0QYp+CW 1c7B+MUtL+23bu8UY3Yklm9Ve9u+V+71u+V7heoSIPWQoA0szZv0L3oy91MAGQwmT9jvB0k0 X1WqOT+jOZgfraYe+MfafgITzdnKoKJ7WGyeFvPrHbTF/M0O6skwAaxgnNRq1Wn0uTrhoM71 knIUjEpZys80Gti1s8ow1agLztIgSBKnEcYkjHG0rVcYJYSExENWuzD0SeZnlmJcNc1bpc1b JhtkB1OPcQ6eyDxrHbr8Q5uOeqCyj4W8rDl39uPCvrbqdqhps+aAJc25uGEVwAe2xU6Wc0J2 wRUCtaceLQrwDNyvxVFbtgoEj4zB84w9vWVlVcUKMzKT55lHDjezFBvmpob9sEsAH5dcdfSd 9p3Wzg4W9i+DHw3g34Hn/SJXKLQWgM3wbmmhRmYFD63J3NPHvv2MJ2Q4IwFEOoA5SMIsIk7w xsGxH4c4yDpHCOIsCMg/+4ECYzoLPOcEj9C3qy/X1poz+AZ1HhSFQKH/WlDFPKQMv5CAvd9Z tn29MOBJvYN1HJaXa3NrDeocDLYRzZX7AHmc2qDOxMmH206G5HVpndESaHU/G/3r8tKHv15F vSEDx1fWVWluzi8W2sjG7gXjdgQ8hjHMCCoNquyBafwUU7cHj4Ap9hMc96CGJMEkiq1CLxdU 30+fB1XKjzU7GFSIqV3SGTaqM/0xQE2iGIB1OzVMSBp+B/V5UO9qww/HFMLjNqZJF2YPDr6E pCnu03AaJp9l4a3gG4dxEAyJb6hNhvTaJ+EXEHyhlmJKUL5jp7oY/K9F/ZmSD1Da7pj368I+ 5NJtb0qP5E0xTnAQBd8jxFAr7hP2b67RhWKlPhhWDOeDbVxdwXyEyB8HSZxGcJqxpTjx4+Sl 12j74HrVtLwuanM4ruMxcsjogPRxau848YOQdBt2d/EdERy8oOJ7H2Ch+J9/QtCnOTyvYzjf bm9Z3B+gDs7sQQInJTgyuz2bpFCuPanAA+xD7u+OVS8gs++D7JtmxsqSlTu27Ldn9n0mPlZm x7CVn/iTOywfIQdEEY4y66+QA7I0xk/7NfixP72AY/o+sF4JXosjRImx8TYmgO3m27c3Xx5H CZLhNCLuZLE5qBMM/3HfhkshoGSO4MtduP/8AQDpT1OPhNBiQbO+X2XbKL8z1qIFlNeoFoi2 LQR4YaDV9WpHMPi6cht2ytNNeazeGUmJT8LuSB4lGY4S5xgb+OKABEkE/mO7qNBng5Rg08D/ Gb7HoP0GfbAariZcnx6dIASAubMZ6iMqMvQj0x2ucmGQrCy2UJd1HD3Gp+i1KFFdobVcIGj4 IeYSAdyYIDNng6yf3Y/Ctd5Q1xRGDV2jGUMLIVjBtKZqjSTc6MwZLU/3chzXpeuuEWA43CwU XP1J2+ula/fBnQ4oBf1BeNTCmix+QLohgZ5fDX3fe9uONQIa33bQUmAGsjsxXEWUC7jrqUXJ qlrUxnY1GdwuKeicCwZrBieFkuZu3cJ9hWlupDTOU3pJ1uU70XbUTwdDuIg6/xsAAP//AwBQ SwMEFAAGAAgAAAAhALIVztHpBgAA2iAAABYAAABwcHQvc2xpZGVzL3NsaWRlMTIueG1s7FrN bts4EL4vsO9A6LhAN5ZlW7YRp0izbVGgTYs63T3TEh0LpUiBpB1nT/ss+2j7JPsNKfkndpq0 SZsGSA82Y5Gj4fCbmW+GPXy+LCVbCGMLrUZR/HsrYkJlOi/U+Sj6dPbqWT9i1nGVc6mVGEWX wkbPj3795bAaWpkzrFZ2yEfRzLlqeHBgs5kouf1dV0Lh2VSbkjv8ac4PcsMvILWUB+1Wq3dQ 8kJF9Xpzm/V6Oi0y8YfO5qVQLggxQnIHze2sqGwjrcxuI67k5vO8epbpsoKISSELd+mFrsQs RtHcqGG9pWdlkRlt9dTRmmHJs+GilBErs+Gbc6UNn0iYp1z4Xz4YYYVZiGPnTDGZO2Hp0fC3 RnZ1Gw0rEqKc3+CW1Y5g/Gwsc/q21ZkRgkZq8dpU4+qD8Y9PFx8MK3IcacQUL6FadFA/qKf5 PxWmYXBwZfl5I4kPl1NTHh3yIczPlqMI+LikTyziQ7F0LAs/Zutfs9n7PXOz2cs9sw+aF0CD 1UtpV2FHu9tJ0v4AOoQtnRVOChavdhamcyx/q7PPlimNvZIJwhaz00UjkPZNr6hmzF1WsI4j UfW88NDbpJlvYVdvMLd8ofNL2vwE3ySED3H65fHc6Wnh2FQrN844YWHQwj8vcnOytG7sLqXw BsQ2+dDLMDguycnphHr2aQynK92JFBxOWRvbHZ0QVk1htWJ6yvJiOhUGAGF87maKlToX0h7C og4H6sXiE2/ARhqtMQymvd7Anca47xdcsoT0B9qC5fx4EzKb5qGtXAFLu9VPu73EQybuxp1O 2iV5a+C0k7QVJ2nECD7tTqvfTvq1xRpRlbHutdAlowGsIyVcXUQkhS/eWgd5tM16Fv2s9KtC Sv8eqdgFzr8LNfwKq2WR01Oa5x1bnEjDsFMgYBlwggfrWRAtlTchIYBMYenwaLlUH8UULgb8 x0E4xb61PJ5lOJxGpp9Ny6Z4+2phcvPCej4tFTjwzK0Wt29evFrh3wxorhaXBVC7T4BcqUxQ xvyw+7DrW+Cnu4Wfzp3wk/TTVtKGRKDjC/hBinrCz3XAe2z46W3hx8eLb48/g37c4KfdT+O0 76PLVvyJUwJYjZ9er9tE7Kf4EyLrY8MPkklNDsBOXugl622FIEap0IdsbI9Yz5r/3JDMOp1u miKhh2CUJu3YJ8cNMLUGbY82AlOSAHrpl3OZQTT3IfimRObDbkg/TSbfpBS2Ivbxqqhz4ZqY 7HINn8Swdv4Kwd1TnynPwFXGl+VEg81mM26sQJ5tk+o08RS03w9zMf0YjIV0G4iPoSm7zOVv ROseWWpCqRFExTjPDmn2Rm7dycAhY4a0JuflO52HzJx210RqlbR92t+QRownaOWO3ihZKHFn KjS4CiUfPVbR6NuhFCedQQJKcj2Ukm7cQrDycennhtIjgsXLciLyXORsYvQF6rM7A4SKkVW+ OqvjzeCaeOPRvypMTmYg++LYQJOZ4Dnqw2uqFIrCFKc2oxObXMA54LZg/tpHkCZb1VVaF9Gn VxOn9iDpEf/1TtxUbEnaA/euE18XrDtMgBM1khpGXfPuW8cqIsZEugddvJ/2vEHHy8IJlDlF OYr6VBzVlQ0Z4KXKvYKOFzKMd6n3vthHap4t/+KmqhV12OKpHs94tbdICHPDWdw5ah6bgm8G zXo/kzlO1/hYOor+++ffOgvcHDQ7q6AZbHH04SJnFrKA2YvCzViyBdlrS0cKwGtZbMKtoICI rLQ2ujsy+bdIqzVjqETd5ZYAHJivZ8NHiMU7iea7m+y4qpi+UJZJfV4o9unNHh3hUA2WblHR kJfvsIrYn/WeXPAj3Tzpttu9ur7uxHGrFarnNSXZcvMUQaF/X5Tkyc3Bje7Lzf8s7BzNFmfm Fg21udjXxWmc68H8yjeZMq6YFOgX83OBvrCmyFRd5I9EYbEsrEMPmllhqeG9T+2vjw2gadsV R+xT+UPHhl4vjRsK0Gn3dygAfmqjRVlzzFY6eKIAq47u3sKJcXmOdmzomv34xHaqmRJwN6fh gXwhGEemy1DGgfDcS47bKXdiXwQ+NI7jTq9T4ziJk4TaNVtUdgvHPsfd0EJ+orJ7GgDfnZe9 VHRDZtl4/H4PWh86uzXaWWc08oO/UfkJ1Twe3zO3jVfXPU35Grpae5weTvdV/bKk3181OToD eO5Ov+ypyXG1aX8Pva+xQGXGnfiqJoevgsJFMobN3XImzTtevV/4Nh9u9VG847YMP1XgUIAD TV1PQU1luLIF3cd7rLgCl0znhBqncFFHA6hGX9mZau6m8zku/wuFLlKh0B2IGC69HUrLUaSI ZoJaodFxFq5oy49aO19M15KIqwXRNKpfhyH+Z8LR/wAAAP//AwBQSwMEFAAGAAgAAAAhAHyu UFzIBQAAZRsAABUAAABwcHQvc2xpZGVzL3NsaWRlNy54bWzsWd1u2zYUvh+wdyB0M2BoalH/ EuoEXdoUKbamSNIHoCU6JkKRGknbca/6Drva6/VJdkj9JE7c2m08YENzY0sUzyHP+c4fD18c 3dQcLajSTIqxh5/7HqKilBUTV2Pvw+XJQeYhbYioCJeCjr0V1d7R4c8/vWgKzSsE1EIXZOzN jGmK0UiXM1oT/Vw2VMC3qVQ1MfCqrkaVIkvgWvNR4PvJqCZMeB292oVeTqespK9kOa+pMC0T RTkxsHM9Y43uudXlLuxqoq7nzUEp6wZYTBhnZuWYDmwWY2+uRNGJdFCzUkktp8bSFDUpi0XN PVSXxemVkIpMOKinXriR94pqqhb0pTGKTeaGavup+LXn3eyyw8YyEcYJuKa1Q1B+ecEr+6+b S0WpfRKLN6q5aN4r9/nd4r1CrAJIPSRIDVvzRt2Hbpp7FTANHkb3yK96TqS4mar68AUpQP3o ZuyBfazsLxCRgt4YVLaD5e1oOTvbMLecvd4we9QvADsYFrVStRI9FCfqxTlbEI7CQSg784FE Pbl2WumXGmTBeRaGaeokwjiIEhyvyxXFaRBEgYesdFHkB7mf2xnDrknRKG3eUFkj+zD2KOdg idSz2iGL37VpZ/ez7LCQJ4xzpz8u7GcrbouaNisOWJKCi3M6BfhAt9jxckZIj7lCIPbYI2UJ loG7vbjZlmwKjAfCcDthN9+S0umUlmYgDrYTDxRuZSluiWsG/rCJAR+2PG3nt9K3Ujs9WNi/ DH7cg38JlvebvEGR1QA4w7uFhRqZGxi0KnOjd217iyXkOA9CiHQAc5hGeRw4xrcGjv0kwmHe GkKY5GEYfN0OFCjTaWCbEdxB3+6+WlltTuAfxFkqAoFC/zkninpIGX4sAXu/1Wzzcm7AkjoD ayksLdfmwirUGRi4ESmU+wF+nNigTsXBh4uWh+SsssZoJ2h1NRnsy/cz33dODqaub6fBm7Km SgpzeDzXRtbWF4zzCBiGZ1gRROpF2QHT5D6mzgf3gCn2U5x0oEZBioM4sZg9gepw+hKoUl4z +mhQIaa2Sad3VKf6fYCaxgkA6zw1SoMsegJ1u6deMsMfjymEx3VM0z0F3yDIMtyl4SxKH2Th teCbREkY9omvr0369Nol4R8g+EItRZUgfIOnuhj8r0X9iZJLKG03rPttYR9y6bo1ZXuypgSn OIzDpwjR14onJ5DKt+Ty8zN0rGilHw0rhvPBOq6uYN5D5E/CNMliOM3YUjzwk/SpRtse+U/r hrOSmcfjOhwj+4wOSO+n9k5SP4yC1mE3F99xgMOn4ttiOBTfUPzPPiLo0zw+r2M43667LO4O UI8+VoUpnJTgyOx8Ns2gXLtXgYfYh9zfHqt+gMy+Syh+XU9oVdFqg8t+f2bfZeF9ZXYMrnzP ntxheQ85II5xnFt7hRyQZwm+36/Bd+3pBzim7wLrqeBM7CFKDI23IQGsN9++v/lyN0oEOc7i wJ0s7hzUoQuX+GBWtg2XQUDJ3QSIh//XAwDSH8deEEFZhiZdv8q2UV5J8fnT3wbJpUCkaY42 xIBvq7Lxg+5K6zJ78MUgCZM0aX0xTuI0SV3WuEUtCfIkjTrUMPT8w2BL8/Q/f25bA+st9L8Y XEm4/jz6/OkvxKbIzCh6eTE6v0CVpLpFs2K6uwVAzOge3GfwgvRMznklfjGI6Gs0h4MVMhIu YOBwh0pbkCMmYICgcM0UvnC6a7eHJkRT6/PQy+wrf2tcaj2lfJWH65OZQ9QQZVbWFJ8hCdcJ bi8C0S5FoS5lgCgCLWesnDn5BWhkQS0VFCggHtKUAietl1KBRN21xsYM99C6XQexveKAx/7W o+TqD9KcLVwrEu6bQF/Qu4ShBm6YYPN26u0U6Ecy6Elf2VaxEdCUtw8gmmsdX4r+mqSawz0U ExWdMsGM7bhSuPlS0NUXFG7IIKtBuXW5akCxpj6X0thiBlZynOC/Y22fuuXgES7JDv8BAAD/ /wMAUEsDBBQABgAIAAAAIQC7xGyxPQUAAGcaAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTExLnht bOxZbW/bNhD+PmD/gdDHAYlF6tVCnKDLmi7F1gRJ+gNoibaJUpRG0o7dX78j9eI4cWe39oBh SQLYtHR35N1zL+Tx7GJZCrRgSvNKjjx86nuIybwquJyOvM8PVyeph7ShsqCikmzkrZj2Ls5/ /umszrQoEHBLndGRNzOmzgYDnc9YSfVpVTMJ7yaVKqmBn2o6KBR9BKmlGBDfjwcl5dJr+dU+ /NVkwnP2W5XPSyZNI0QxQQ2sXM94rTtpZb6PuJKqL/P6JK/KGkSMueBm5YT2YhYjb65k1qp0 UvJcVbqaGMuTlTTPFqXwUJln11NZKToWYJ5y4Z7cKqaZWrB3xig+nhum7avsl052vc8KaytE GqfghtXOwfj5vSjst64fFGN2JBcfVH1f3yr3+tPiViFeAKQekrSEpXmD9kVL5n5KIIPB4Bn7 tJNEs+VElednNAPzo+XIA/9Y2U9gohlbGpQ3D/P103x2s4U2n73fQj3oJoAV9JNarRqNXqoT durcLKhAQa+UpXyhUceunVW6qXpd8DANgiRxGmFMwhhHm3qFUUJISDxktQtDnwz9oaXoV02z WmnzgVUlsoORx4QAT2SetQ5d/KFNQ91R2ceyuuJCOPsJaV9bdRvUtFkJwJJmQt6xCcAHtsVO lnNCdikUArVHHs1z8AzcrsVRW7YJCO4Zg92MLb1lZZMJy03PTHYz9xxu5kqumUsO8bBNgOiX PGnoG+0brZ0dLOzfBj/qwH8Az/u1WqLQWgCC4dPCQo3MEh5ak7mnT317hycM8ZAEkOkA5iAJ hxFxgtcOjv04xMGwcYQgHgYB+Wc/UGBMZ4FdTvAEfbv6YmWtOYZvUOdRUUgU+q85VcxDyojL CrD3G8vW7+YGPKl1sIbD8gpt7q1BnYNBGNFMuQ+QJ6hN6kyefL5vZFSCF9YZLYFW03HvX1dX Pvy1Kuo1GTi+sq5KM3N+OdemKm0sGBcR8BjGMCOo1KmyB6bxc0xdDB4BU+wnOG5BDUmCSRRb hV4vqL6f7ga1qr5wdjCokFObotMFqjP9MUBNohiAdZEaJiQN30DdDeoDN+JwTCE9bmKaNGn2 4ORLSJritgynYfKiCm8k3ziMg6ArfN3epCuvbRF+BckX9lJMSSq2RKrLwf9a1h+r6hG2tlvm /b60D7V005vSI3lTjBMcRMFbhuj2ivvU8rsbdKlYoQ+GFcP5YBNXt2E+QuaPgyROIzjN2K04 8ePkte/R9inn12UteM7N4bj2x8iuogPSx9l7x4kfhKQJ2O2b74jg4BVtvvcBFjb/s68I+jSH 13UM59vNkMXtAergyh4kcFKCI7OL2SSF7dqzHXiAfaj9zbHqFVT2fZB9X45ZUbBiS8j+eGXf Z+JjVXYMofzMn9xh+Qg1IIpwNLT+CjVgmMb4eb8GP/Wnt2O6O6ZfS8HlEbJE33jrC8Bm8+3H my9PswQZ4jQi7mSxPqgTDP9x14aLcRy7HsG3u3D/+QMA0l9HHgmhxYLGbb/KtlF+X40VLxCt 64st4f99G2yIjedheKxuGUmJT8LmEB4lQxwlzhXWgMUBCZIIPMb2Tf8XeX0Dpo/Q+eJwGeE6 8+gEUTTrgUNwJcGZRpVEVCLWJnPUJlc0XqGCTbjk9tbidC+QXQ+tafLDsOv750L9SeubhWvG wY0LHAeheweParhjgY2ZJV2TQEeOQ1d2apulRkJb2g5qCsxA9iC7i4JiDjcxXLYrtD1HBnc/ CvraksEdETgUbDgeVjXcJpjyrqqMLecwk5ME361oO2qngyFcE53/DQAA//8DAFBLAwQUAAYA CAAAACEAP+iFqQ4FAAB3GQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU1LnhtbORZbW/bNhD+PmD/ gdDHAalFvdpCnaLL1iJA1wSJ8wNoibaFUJRG0k7cX7+HlOTEjttkszFsyReLlu5OvHvujaf3 H+4rQVZc6bKWY4++8z3CZV4XpZyPvZvJp5OhR7RhsmCilnzsrbn2Ppz+/NP7JtOiIOCWOmNj b2FMkw0GOl/wiul3dcMlns1qVTGDv2o+KBS7g9RKDALfTwYVK6XX8auX8NezWZnz3+p8WXFp WiGKC2awc70oG91Lq/KXiKuYul02J3ldNRAxLUVp1k7oRsxq7C2VzDqVTqoyV7WuZ8byZBXL s1UlPFLl2flc1opNBcxTrdydS8U1Vyv+0RhVTpeGa/so+6WX3bxkh40VIo1TcMtqpzB+fi0K e9XNRHFuV3L1WTXXzaVyj7+uLhUpC0DqEckqbM0bdA86MvdXggyLwQ77vJfEsvuZqk7fswzm J/djD/6xtr9gYhm/NyRvb+YPd/PFxR7afPH7HupB/wLsYPNSq1Wr0VN1ol6dixUTJNwoZSmf aNSza2eV/lUbXehoGIZp6jSiNIgSGm/rFcVpEESBR6x2UeQHI39kKTa7ZlmjtPnM64rYxdjj QsATuWetw1ZftGmpeyp7W9afSiGc/YS0j626LWrarAWwZJmQV3wG+GBb6mQ5J+RnQhGoPfZY nsMzaLcXR23ZZhC8YQyfZ+zoLSufzXhuNszB88wbDvfmWj4wVyXiYZ8AsdnyrKVvtW+1dnaw sH8f/LgHfwLP+7W+J5G1AILh68pCTcw9blqTubuPffsZTxjRURAi0wHmMI1GceAEPzg49ZOI hqPWEcJkFIbBj/1AwZjOAs85wSP07e6LtbXmFFeoc6cYEoX+c8kU94gy4qwG9n5r2ebj0sCT OgdrOSyv0ObaGtQ5GMKIZcr9QJ5gNqlzeXJzbXfPMnN6ttSmrqxDG+fWoMUabNhXv58XAJPs AuMC6QjAUD+lSYdMFKQ0iJN2633qeb3I1PVtyQ9GBtmtTf99yDj7HQOZNE6AjouZKA2G0ZtB ZlIacTgwyDbbwKRt1jo4lwXBcEi7qjaM0idFbStikigJw76O9KW+r1ZdTfu/5DL0F1xJJvbE jEtpP86EU1XfoWfbw/z3UiGKxDauwyPhmtCUhnH4BgPu6oKcKV7og7Gh6F63wXHt3BGyYRKm yTBGr20bxcBP0jfTQZxXjSjz0hwOzuak0pcqwHWc9i5J/TAK2tDZ39/FAQ1fY3+HJnHxjeA8 f3jBojgHbQcP7Rrtg0tWmKKjxtHKRU86RDOx0+SF1EdRa9vvV1WyqikvCl7sCZ5/sWRRRMYO su54c4S8GMc0HlnPQV4cDRO6e8Kmj5F9TQercylKeYSg28w7Nklxe+bxz8+8AQYacdcn7sxz oiBBDOJQ5+Yevk/bTPz9scd/vkUk+tvYw9wRDcC0GxDYI+8NOj7CkCMxTSlzN2kjFc8XTJb6 8FMxnH03ro41sEC2pDF8A2EVp5E9GW9nzDeD4KS+5ZI0TGvMlo+J3ZORRpu6jpATkzjG0bmt dnEYRTTZAS9Ik5RG3bQpesXhd2HbEzJXTBpi1s3L0qUbR7VDbyz7OXgu1B+suVi5YRe+QOAo iGkpbjXwC3SRlvSBBMOtElPKuR0eGokxrV00DMwgm8h+cF4s8WWilAWflbI0dgbH8S1EYc4r Ob6ZILrRWE2w8bFnqqu6NjYI8SYnCddOtF11r8MSn01O/wIAAP//AwBQSwMEFAAGAAgAAAAh AA8/YgyGAwAAVggAABUAAABwcHQvc2xpZGVzL3NsaWRlMi54bWysVt1u2zYUvh/QdyB0MXRD U7sZNqxa7KLt1m5AlwS1+wDH1JFFhH8gKcW62zvsDfck+0hZKdqmQQLUFxJFHn4833d+6LMX B6PFwCEqZ1fVs6fLSrCVrlF2v6o+bN+c/FqJmMg2pJ3lVTVyrF6sH3135uuoG4HdNta0qrqU fL1YRNmxofjUebZYa10wlPAZ9osm0DVQjV6cLpe/LAwpWx33h/vsd22rJP/uZG/YpgkksKYE z2OnfJzRjLwPnKFw1fsT6YwHxE5plcYCegMzrKo+2PpI6cQoGVx0bcp7akOyHoyuhJH1X3vr Au005DFDmbkMHDkM/DKloHZ94piX6h9nbH8fD30GsakQ/ES1NcSXG93kd/TbwJxHdngb/MZf hrJ8PlwGoRqEtBKWDFyrFseFo1n5tDDDYPHZ9v2MRPWhDWZ9RjXkF4dVhfwY8xObqOZDEnKa lB9nZXdxi63s/rjFejEfAA9uDs2sJkZf0jmd6WxV0iye3bCaTAlb3zl5FYV14JnpT/Tk+TCD Zc4Z3ncijR7KpAx1tJsWix6zfYSmRax0eOWaMRPf4V0mqdYxbdKouQgCt6kGOB6QX1MuIrYn HzYZneq0RmIYFfkMvBNkL8Z4Yh+OnPExnAT4ugw/zTK8djYhScSlJsmd0w0HcZpPQ4rMlB8o imoQ0lm3h+iRKaISzMs+uVYl0cK3jaRcF89Pf14idbTdePmem17mqsUpS/yK8rOmGeNhkr6i yI1wVpCwvdmBv2tFo9qWQxamYa/dmFuGkB0FkomDiknJ+ESMrhfXSmuxY6EBktyiDc7A0KHV xLJuuSwIQ1csaOf6dEvwSgTxyEEf9FG9uzPhT3dd8KlPHZxTkhILDEWPzvFtj9hzKsjJXbGN YFm+LBrLAEref5vTtvD9AqHvxD4Q1M61lc8Cn68fcFetnDso8t8//xZvQ68REAqMwk4CgWzE 92T8b6KleEdE7sJ/y5YDaT0+EZJDwn30eYZMyYH6yqkh0I+l7hsWngLi1WsKN5nyGJGLLGLn rq0AUEDS4JXj2TqtXb75frhFhi+rvhT/1NMxnNu81OFv8hdD4YMLFkn8ukx5AKPas+lHE7QS ZbCQu0Cy7yJaDdodYTPMtnBwuheaHhevsg23yqrEFbzGVR/SqrKMvwRoMa7h7dQizXvnUqnU I1L2fILOo+NxGOJfwfp/AAAA//8DAFBLAwQUAAYACAAAACEAKlzy9KMFAADuGwAAFQAAAHBw dC9zbGlkZXMvc2xpZGU2LnhtbOwZy3LbNvDemf4DhsdOHBF8kxM5k7pxxpk29ljKB0AkZGEC giwA0VJO/Yf+Yb+kC/AhS1YqpVYPaXyRSHB3gX0/8Or1quSooVKxSowd/NJ1EBV5VTBxN3Y+ Ti/PEgcpTURBeCXo2FlT5bw+//GHV3WmeIEAW6iMjJ2F1nU2Gql8QUuiXlY1FfBtXsmSaHiV d6NCknugWvKR57rRqCRMOB2+PAa/ms9ZTn+p8mVJhW6JSMqJhpOrBatVT63MjyFXEvlpWZ/l VVkDiRnjTK8t0YFMM3aWUmQdS2cly2Wlqrk2OFlJ8qwpuYPKPLu6E5UkMw7iKRu7ciOporKh b7SWbLbUVJlP2U897fqYE9aGiNCWwS2pnYPw8wkvzL+qp5JS8ySad7Ke1DfSfv7Q3EjEClCp gwQp4WjOqPvQgdlXAWDwMNpBv+spkWw1l+X5K5KB+NFq7IB9rM0vIJGMrjTK28V8s5ovrvfA 5ou3e6BH/QZwgmFTw1XL0WN2gp6d64Zw5A9MGchHHPXoykql32rgBaeJ78ex5QhjL4hwuM1X EMaeF3gOMtwFgeulbmoghlOTrJZKv6NViczD2KGcgyVSx0iHNL8q3UL3UGZZVJeMcys/Lsxn w26rNaXXHHRJMi5u6RzUB7LFlpY1QnrBJQK2xw7Jc7AM3J3FQhu0ORAeEP3DiB28QaXzOc31 gOwdRh4w7M6V2CCXDPxhHwE+HHnewrfct1xbORi1f1n5Ya/8KVjez9UKBUYC4AwfGqNqpFew aERmVx/a9gFLSHHq+RDpQM1+HKShZwlvDBy7UYD9tDUEP0p93/tnO5AgTCuBQ0bwQPvm9MXa SHMG/8DOvSQQKNTvSyKpg6TmFxXo3m0lW79ZarCkzsBaDIPLlZ4YgVoDAzcimbQ/QI8TE9Sp OPs4aWlUnBXGGA2Aknezwb5cN3Fd6+Rg6moDBm/SmCrJ9PnFUumqNL6grUfAMjzDjsBSz8oR Oo12dWp98AQ6xW6Mo06pgRdjL4yMzp6VavX0JaVW1SdGn6xUiKlt0ukd1Yr+FEqNwwgUaz01 iL0keFbqYU+dMs2frlMIj9s6jU8UfD0vSXCXhpMgfpSFt4JvFES+3ye+vjbp02uXhL+D4Au1 FJWC8D2eamPwfxb1Z7K6h9J2z75fF/Yhl25bU3Iia4pwjP3Qf44Qfa14eQmp/EAuv71GF5IW 6slqxdAfbOvVFswniPyRH0dJCN2MKcU9N4qfa7TDkf+qrDnLmX66Xoc2ss/ooOnT1N5R7PqB 1zrs/uI79LD/XHwbHQ7FNxT/i88I5jRPz+sY+tttl8VdA/XktsqPoVOCltn6bJxAubZTgfvY hdzftlXPmd22VW/LGS0KWuxx2W8js2Nw5R17ss3yCXJAGOIwNfYKOSBNIrw7r8EP7ek7aNOP Se1XgjNxgijxaPaCTzV8eRglvBQnoWc7i02j7rl+FKYwKDBjuAQCSmoBIB5+qw0AUp/HjhdA WYZm3bzKjFE+UFogf8vzv1DI7xJAM6KoUTQMsPpyz1CU23HkSGp2TKLPUU2kXiMCuUa83jrV vxn04EeTntZ9TxAXTNkA6cPGhTAK4yi2GWxjQaGfBn4Is+P/lwXhaNeC3sNQjsE9ib00QH/9 8Sdic7Sulkh8nWk9oHwC03pAbY9pvbAH5OwT5Wt0T4RGBHVtJoILJDSZXL9E0wVFhNumV7OG Iqag+uEcxqxwp4Q0fM1NA4OYsC+krl8guLVCC9L0AG8mMB+oVmsLAFdeg5yOMm07ymzvWuCx v37JufyN1NeNnYnCxRccEIaosFTDrsCrAd2AwGCUwXD8zsystYDbAfMATmZn2FPR39cUS7gQ Y6KgcyaYNqNfCldwEq4XBIVzQ3qFum+6rsHZdXlbVdpUVbCTpQT/HWnz1G0Hj3Bbd/43AAAA //8DAFBLAwQUAAYACAAAACEA1KjFVd8DAACMCQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0Lnht bNRWy3LbNhTdd6b/cIfL1ooct00zHMue1G0aTx1bY8vTNQReiqjx4AAgLWXVf+gf5kt6AJJO HDuts2u1ICHg3gOcg4MLHh5vjaaefVDOLornz/YLYitdpexmUVyvXs9eFhSisJXQzvKi2HEo jo++/uqwLYOuCNk2lGJRNDG25XweZMNGhGeuZYux2nkjIv76zbzy4haoRs8P9vdfzI1Qthjz /VPyXV0ryT872Rm2cQDxrEXEykOj2jChGfkUOCP8TdfOpDMtINZKq7jLoHcw/aLovC1HSjOj pHfB1THllEbIsje6ICPL0411Xqw15DF97ll6Dux7fhWjV+suckhD5TcTdvuUFbYJxMZM8J5q RxBfXukqvUO78sypZftffXvVLn0ePu+XnlSFLS3ICoOlFfNxYAzLfy3C0Jh/kr6ZkES5rb05 OhQl5KftooA/dumJJFHyNpIcOuWHXtlcPBIrm18eiZ5PE2AFd5MmVgOjh3QOJjorFTXT8ztW Q6hA6pmTN4GsA89Ef6Anz/sJLHFO8G1DcddCmZigxrhhMOsxxQdomsWK259ctUvE13jnTlHq EK/iTnMWBMsWJcDxgPxapEPEdnZ9ldBFGY9+4x2dNA5GDofgHiF9TsATuZh2mgPNQYTPS/Hd JMWJsxFGoaUWkhunK/Z0kGaETSbaXyiMqrCtk3ZfokmiidNgXnXR1SqStletvOSqk+mcAnMf v6z1pGLKeCgiNCcc0bNF8f0PP6JgFKRsBZKLYjZ2pLx19xrc8zbW4L4ovjV/zHQc1F53aRHn nRm3WeCMKrlkr1w1riCfls/sGIV3i+Lg5bDatFXXONIkuthgGUrmY0mGZSOsCoZm9LvSmjBK om2pC3jT2rvbnBXygGFhA7maNhwjamHuROQ9WK6O6bSm4PbodkKccNZMgVsQiUzOE5s1VxVX 0GaaOOdaFz9KTsuRTmuWUArLyxNKz0lOJXSgSnmM6d3xI5bMvsTjv7cdF9jdhjZejAag93/+ lbfnHdhWvEfKtFpJBSkg1eUFJcrh/8Vx5W7YUitCSG752GxwyM51n9gM1+2wu/ddukeNux3M lHJgvuyDmMFr73BAYIvJY9HlvxYG77OX96hXApq6GwVV36zenlGumFlXDHQhAuL68pTyVcn/ IDHbagn3Xj4sjkMBHN32b2EP62Qul8NNiOZ0OUrt34r2os8VGZ8lkf1J7mohJ+pjCv0QguKr DAZS3Yz2LKA445IQw326stNtWnX4XEnFqFZWRS4I13QUHpXJMj6kUJThvtVwsZhL53I1wkwZ Ce8ROrXG6dDEt9TR3wAAAP//AwBQSwMEFAAGAAgAAAAhABRfis17BAAAtw0AABUAAABwcHQv c2xpZGVzL3NsaWRlMy54bWzUV91SGzcUvu9M3+HM3iRtY0wg6c8OhqEk6TBDwYPJA8iS1qui lXYkrcG96jvkDfMk/Y52l4SSNHAHvrDls0dHOt/5+3bv4LqxtNYhGu9mxcut7YK0k14Zt5oV 7y/eTX4tKCbhlLDe6Vmx0bE42P/+u722jFYRdrtYillRp9SW02mUtW5E3PKtdnhW+dCIhL9h NVVBXMFqY6c729s/TxthXDHsD/fZ76vKSP3Gy67RLvVGgrYi4eaxNm0crTXyPuYaES67diJ9 08LE0liTNtnojZn1rOiCKweXJo2RwUdfJd5TNkKW68YW1MjyeOV8EEsLeJp1lsyDjjqs9WFK wSy7pCM/Kn8cbbf3uWHLRlzKDt5CbR/gy4VV/Bvbi6A1r9z6j9Au2nnIj0/X80BGIaQFOdHg asV0eDCo5b8OalhM/7N9NVoS5XUVmv09UQJ+up4VyI8Nf2OTKPV1ItkL5SeprM++oCvrt1/Q no4H4AY3h7JXvUd33dkZ3bkwyWp6eeNVryqw9cTLy0jOw092v3dPnq5HY+wzm29rSpsWyCQ2 Nej1DzMeo34EphmsdP27Vxt2fInfLBSljWmRNlZnQHBtUcI4vgC/FVxE2k3eL9i6KNP+US2C kEkHE5ORcQ/+J8CfN+Eb+3H0eA6WPRBfh2N3hOPIu4RkobkVUtfeKh1oh09FqoyuPxAcoxDa Eb+H4MKuoiKawy75yiSqcLeFFFwfv+283s7JA2d7EFn5LoaAnFChJ7Pi1etf0C8KMk7Bv1kx GQS8b9m9g+kcxQpuz4qfmr8mNvVgLzs+/7RrhigD+KWRc0DvFWsw3JwIXwkYxb9nxc6r/rYc JaSVsCS6VDtaR9q9FbtvGqGliNoabqG72/iMCRHUw+wMeUStCGkz3ObjPx/oylhLqdZ0uMhS YGWkSDrLOjQj8lVei7Ylk3CX6gX50O9DjNBJN+QdLRZnVAXfkHgcHh6r+cEthPoqyaWSA/jY 0uTsyhFjjBRRHl0okR8kHCbldRzCND1fkAyaY4TxSgodoZ8VHJ68yaH1r/G0bS3HEnOOnusV LVBJEZNVakI7SWgmP3AkTW+Yz+7NKloiQx5HGJ/rrdUWLbSOGKMkIklruF0hKUcfnlSUT7VW qJkKI7r+LNTuc3Efb9r4jm7Jk7/UDsHyYFrMGgjMajWxCLXi8nta6f5mTGjOu5sc5lSVtXBO W1p1IigSK/C9iD7jV11O6UgrnRIIITo7CKa18J7rIOcuiwW1tQGxwxLT8vJpwXIcUcVkmtYH kGeMKE+XWreUO7HJHeKmpiWPbnAj1DDaxZPzk4cOB/9ZvVkGo569IAMBSGduXrHWGEwi+A6x vdLLrGrgcHDCxv9xVjs1x8g+v8ujbk2Ab6ndpVOZVfWkGcuRR0sb/hTt2ToTArzB4IJHWdQi AZktQPWTCjiaafCA6VVyJxEcDnxSZFopL9xIvFWHNxsmLpVxJukCHQOpHsBinMY7F7ibV/qi 56DNufcp85LBEt+8N82r4Tgs8dq1/y8AAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcB AAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHOEj8EK wjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LIC Qd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT 5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6 yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA cHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDYueG1sLnJlbHOEj8EKwjAQRO+C /xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv 4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKa O/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95 LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDUueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6 EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYg OKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1 UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfV NuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw 4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZP Gt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaL KU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsB AAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9f cmVscy9zbGlkZUxheW91dDcueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk 2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+X i+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZ GsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMA UEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDkueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj 6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS 4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvz f3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQA BgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDEwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MF wePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF 4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn 6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAA ACEA1dGS8b4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQx MS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBv dpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz 3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMi n39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXR kvG+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTIueG1s LnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/Wsa xZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWag CVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCge naUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAA ADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDgueG1sLnJlbHOE j8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A1 1LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44 XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZU sJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAs AAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1sLnJlbHOEj8EKwjAQ RO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E 63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJT ryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqk nN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHOEj8EKwjAQRO+C/xD2 btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9 rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak 1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ 3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDaJLOf1gcAAGguAAAhAAAAcHB0L3NsaWRl TWFzdGVycy9zbGlkZU1hc3RlcjEueG1s7FrrbuNEFP6PxDtY5h8oJL7b0aYom93ASmWpaHmA iT1JTMcXxpPQgpD2HXgD3gL4x6Psk3DOXBynTULLtqhBlap0PHN8ZuZ85568+OKqYNaa8iav ypHtfD6wLVqmVZaXi5H93cW0F9tWI0iZEVaVdGRf08b+4uTjj17Uw4ZlX5NGUG4Bj7IZkpG9 FKIe9vtNuqQFaT6valrC2rziBRHwyBf9jJMfgXfB+u5gEPYLkpe2fp/f5f1qPs9T+qpKVwUt hWLCKSMCzt8s87ox3Ir0LuwKwi9XdS+tihpYzHKWi2vJtGWzHtkrXg71lXpFnvKqqeYC3xkW JB2uC2ZbRTp8sygrTmYMhFSs5cwZpw3lazoWguezlaANLg0/Nbzru5ywRialkBfcktoJQJCe swz/zxbq81s6t/LsCoAcDBz75AVR56YTxq01YSN7tnDs/smLPr4CxHqELzf1BacUR+X6S16f 12ccH9K36zMOPIGlbZWkgNshA7mgyeRjCWSK8dbrC8OJDK/mvMATAYIWnBAU7Ro/4SUypFfC StVkuplNl9/soE2Xr3dQ980GcLV2U7yVutHt67jmOhe5YNQ6YySly4ploM5SRPKG6jWQYn1a pZeNVVZwZxSFuioIxzDG++NW9dIS1zVISSBbTacW4WRlS99I+ZpDt1LxgwjsQorGjfzQi7fl E7tuEuI6SslxfG8AD3iWDaOaN+JLWhUWDkY2p6mQikDWp41QpIZEoq8OUg/F1csqu0YwZvAf MAenAO8vK/6TbbE3Jehu4vg+7C3kgzypbfHuymxrRbBJBSoHb5AyBT4jOxVcngUMpRivRDXP 9YnUlrg5a8S5uGZUqgWAR4YgVviAAzGCPomWve/OlVTEyYTl6aUlKotmubC0N5KSB6cFXFAw QooHuMAYGAIK5qowVPqxX0u8VktQRbtK4uIZPlRJ8N62tliJI6oIKtI9dcUBpUC9kVIzxrSl LH7gBknoyU2etLIg2vfSDzAki62losnr319fUGBSXZod+iKVBj7MLtL2D2vlOU2rMrMYXVN2 B45Skw5zvFjm/O4MJcqHGU6rFRfLOx/RV5p1SLTTfH6A4f2szjdW94qIbdcsr/ahVpcJyGl+ At9G2Fxbn8RAGt2/sL7QC+DvhvW5jue1rtoLA8cNnr7xbXlqaU3GH0vfvGYO2gFhC8gVmY1z GZ1/C1MoTgc9EM41Fcuzac6YfMBccJOAiCuVl4i8FColiYJNEJNZFhJLb93hA75b7SQXwNzx IGqsAwbuJePFnGUyX/k5GXvB5PVg2pu8Dqa9xPOTXjJ2J71X8SAZJ14URU70C4QzGa4z0DSR F3SaL1acfrNSQXNn2IGdpWjEiQ+pYt9xNzYOe+M5aJmdEU5QMDeC1r+JQYGxhmlVYbbdjULS MD/UHuYQliWCP6wIhx20TahgcZ+I5Dmub9KX3UYRJ8H/2ihMhvP0zOJhdTI0OnkOpk6tt6ti dkMzpbf7UM2EEhNY71JOqfj3cthhEHiHlfP/7rFV8v30VLP12IHrjqPQjXqh5wx648R/1XsZ +3HPjZ1kEATJ60k4bj12g5pXgnagx73pqK2mEBNGCcQpHZc3Xvv9u98/ef/ujwfw2qB/pmyG oSnGU8a/JrUFpTYESQFlM8S8kZ1dwmi2cHEOak9xBaPsEkYkTaG+Bwo9MDOwrmZaGs/MQFWi lnwzAxmTmgnMDEQNNROaGbDZJcvLS0h88J9tzSv2lZowI8xQ4E4sOyXX1Uq8yaBmvDEjY6vr +JEfe2EEJ+FD7A7wN5kumztvb9PCGVtaXT3tpYXTt7Q659tLC/dqaXU83EsbdWi1h9pLC52v lm94SzLbd0s6tNFh2hgK4pavrO+3JL7FNwadaWmTf+ALetLSOlLrDzDeAu6fkOue2DGpckdu WkvElSzdG9QYWYTLRzRPnbDpzBGDpAVu6ILMziFvND0PLlS3gJLT8iUHNYXLY2Ov1I9wiiW0 AKB7eLYqU+hN6A5Xnb7EThZ2adKzVGeV8v6QbcGcXp2t3kIHU2ZuHRcIHQ3ge0k5dj/vmsAC E2TdTXPlQWUuOYdG0sj+rPi+xwQiBukgubFAiVpImxsLaYML+5LdbalCCw+6B7dEDB3N05Ht +W6CF8tL8JEgqp6ZMLn7Y8sfRKn6ETcwmFaQ92PKrcQ05jlhShiz1WRJuJXCx8h+/+43NduB SkXvx4Cq3AdV2dsDVdk7CJXUeBdrJQVHBHBAgbiBw40DqHvARetS6snD8estONz4sSznAeFA DLQD8jZwmM5pBw83lnXJ0eBx2zzcR/NkD4gHgqDx8Dt46PblEeOxwz7QAT5KZHlAPBAEjUew wcMdBJHUpjZ8uMdlH3/9edtdHQMciIGGI+zAETi+9E7HCseuaI4JwpM3DwRB4xF18EgiRwa/ Zzzukgg/oLtCEDQe8QYPldtupVfH5a6O1j4QBI1H0sEjjkPZaXu2j//YPhAE2HKrNKyHlVhS 3haKUFGdKdR0bXX7K4oNiSncVRnzKAVLp8JTXvUoKzzTxHj4AuLY5LO75JK/HXnWH7CnPSWQ F+GPOB6jI3BsCrS7JnFiN5ZJ17OF7akSZM7zrEFgYnvS9shXLcRnDdqTR0PSJsv+ZwHtSWzD IHp20rK53Waa3eQSEs/Nd0D45aj5hfjJ3wAAAP//AwBQSwMEFAAGAAgAAAAhAJ5Mi7z1AgAA VgcAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWysVe1u2jAU/T9p72B5 /yalgfCZCKgolGlS16LRPoBxDET1R2Y7GWya1NfaHqdPsmuH0K1lUqXxBxzn3uN7zrm+GZxv BUcl0yZTcoibZw2MmKQqzeR6iO9uZ0EfI2OJTAlXkg3xjhl8Pnr7ZpAnhqdXZKcKiwBDmoQM 8cbaPAlDQzdMEHOmcibh3UppQSw86nWYavIVsAUPo0ajGwqSSbzP16/JV6tVRtlU0UIwaSsQ zTixUL/ZZLmp0QR9DZwg+r7IA6pEDhDLjGd250EPMOUQF1ome0qByKhWRq2sy0kEoUkpOEaC Jh/XUmmy5CCSKP3OXDPDdMnG1upsWVhm3KvkfY2dv6bC3IFI6wn+rZrd5XDWkhN5j5EPg7PA QzwCc+iCp0gSARsXPsJtmvxWM+ZWsvyg80U+1z72upxrlKUud5+Dw/2LfZh/lBAGi/BZ+rpG Isl2pcVoQBJwCW2HGJpp534hiSRsaxGtNunTLt3cHImlm8sj0WF9AFRwONSxqhi9pBPVdKbE MjTnhLKN4inTqHkgWGURQLlS9N4gqYCyU6JiSq/LGtfRdyflG1RJn1q4G9/ARMJXGPQDck1P 1ivkgv2izjcgt9fRbi9UunOaLOHfb5KEG7uwO868VsCIJCtw0JnyPR63OpPLxiyYXHZmQdxq x0E8jibBtN+Ix3Gr1+s1ez9wXRRQtZlgs2xdaHZTWGgHkmgwGNoA7jSTwd2icqSqhyR21Iae D5vRABS2ULU/23sm0znR5PPLbIiBIoFfTQaWlRH/tqNV2zFTyoIJfxoSncKQldWVI18KouGE 2pTazMrB/zKFnVSRdq3IgmcpQ9eFWD7TpXUKXWBSA/RRabzuXpHT9Wsnisa9btQLuq1mIxjH 7Wlw0W/3g6jfjBudTnw56Y4P/WoccwnVHWtTZISdcEbg07SfIk89+/jw893jw68T9Kxv3Woy wtJNTj/8uP5E8psSrjGBQW+gnyZ+K4fv1344PIU4jPp7OPoNAAD//wMAUEsDBBQABgAIAAAA IQAkTnOsaAMAAPcIAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1stFbd jtM6EL5H4h0scwNIIf1b2kTbojbbIiTYrejyAK7jttb6J9hOaDg6Eq/FeRye5IydZgvsrrRa lps0tWe+8XzfzDinb/ZSoIoZy7Ua4+6rDkZMUZ1ztR3jT5eLaISRdUTlRGjFxrhmFr+ZPH1y WqRW5O9JrUuHAEPZlIzxzrkijWNLd0wS+0oXTMHeRhtJHPw12zg35AtgSxH3Op3XsSRc4YO/ uY+/3mw4ZWealpIp14AYJoiD89sdL2yLJul94CQxV2URUS0LgFhzwV0dQK9hqjEujUoPKUWS U6Ot3jjvk0pC00oKjCRN322VNmQtgCRZhZWlYZaZik2dM3xdOmb9VvqyxS7uc8LCgygXEvyV NVcXEMtxJ9iFEjVGwRTigY54AgLRlciRIhIWLr0VCmZ+xxaXhjH/pqq3plgVSxMczqulQTz3 AAdHHB82DmbhrwIzeIl/c9+2SCTdb4ycnJIU5EL7MYaqqv0TnEjK9g7RZpEeV+nu4hZbupvf Yh23AeAE10F9Vk1GN9Pptek0PHSvs2pMCbi+1/TKIqUhT59+kx49r1own7OHL3boJ+IPds1m 4KO1t8BpIMvtZzqvfeJr+A2LJBXWrVwtWCAEjk1SAIcH0C+Ibz2mok8rj05SN8kEp1fIacRy 7tAHYh0zKAgPvQkop0CIAz0CCjwBEM7SBobXhpm7+em3/JwRx9BSEMp2WuQQpefPAKXUEvEg qnIHQ+QrVDsRGwz1BeJ3QzEExjyvf0TdBsrcF+0/ybR/ks07iyibnyyipD9IomTay6KzUSeZ Jv3hcNgd/osP+uWQquOSLfi2NOyidPhOBRopPccDGA5xt3ckHGJ7N6byJTHk4039HiLHoJVj obWX+mdB+o8hyMaZRpHPJTEQoRWlrfu/Vc8o58aFnkdWukwwApfOYSxAmeuiNny7c+g5fYHg fkjQEu4K9C6HAQiDGWXaFDBj/aw/KhAa5w7+j/Ggih+ixEmrxErwnKHzUq5/02PwGHrAVQrQ t0oSGvCR+2TUGc0Gs8UiWiSdfpRlg7NoNM3m0Wz2etif9+bJbNi/7hPrM1dwutva46aMx175 8e37sx/f/jsq9eBeCROsubHg1V9rYSYJ84EUF1UoAPjcgDrOwlIBReP1BtOjicdoP1gm/wMA AP//AwBQSwMEFAAGAAgAAAAhADoTQU26BQAAKRsAACEAAABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0NS54bWzsWd1u4kYUvq/Ud7Dcu0os+A9jK2TFklCtlE2ihn2AwR6Cu7bHHQ8E WlXa12ofZ5+k5xx7wCHAEhKpF80NcezP35y/+Xx8fPZ+maXGgssyEXnftN51TIPnkYiT/L5v fh6PWj3TKBXLY5aKnPfNFS/N9+c//nBWhGUaX7GVmCsDOPIyZH1zplQRtttlNOMZK9+Jgudw bSpkxhT8K+/bsWQPwJ2lbbvT6bYzluRmfb885n4xnSYRvxDRPOO5qkgkT5kC+8tZUpSaLYuO ocuY/DIvWpHICqCYJGmiVkS6pln0zbnMw9qlVpZEUpRiqvCeMGNRuMhS08ii8ON9LiSbpBCk bEFnbiUvuVzwgVIymcwVL/FS+LPmLo6xsECSXJGDj6OmVgWspR7EeDl+EDeT30yDwLAiZNI8 hxRFd2ls5CyDE0N0USalyOlKWYwl54jJF7/I4q64lXTD9eJWGkmMBPWNZru+UMPo3xxgcNDe uv1eM7FwOZXZ+RkLIWHGsm9CXa3wF25iIV8qI6pORpuz0exmBzaaXe5At/UCYMF6USjJovLo qTu2dmecqJQb1tqrCsrg1isRfSmNXICf6H7lXnS90GToM9IXM6MOPVLVuOoixUPjS4gpBUst P4h4hY5P4C+dZGFaqju1SiEFcLxILUoAC2M+/bUKbeM0eNuEg5MsBFPgB5KVMtyqPG99vkNb WKjOh2kSfTGUMHicKOMTKxWXhiLHS1zzDAgVZI9Y4BcIwXJtJhxWcdwfTWcdTUzlbcoiPhNp DKvYaAMUng7bSYHFMJlQhVAiOg974ov+blWa6/kgLVRulud4luVUYdFF53bcjtUDWcPS6zqB 3yWbIQwVEblfZVpHRCfOYHk0E6BTk4qymZQ6hwYoyhWVe5LHsG/xEI2czK9BPyk/VYqN8o++ abto6US72Ug5HdpQFDWh9uoo1s5TVqRCO8BMZ8MaWC5ZcAyr1XvKilQ1q7thtRzf6iL4KFpC Pg4BctW0XoO2Z/fIhlNpkaum7W5obbsHJrzAWuSqaf0Gre86VIenWotcNW1vQ4ucx6dsR2yR q6YNGrRdz39RypCLFKW5J0iocBGourX40+rPEi7cuaRb5YuFy9XCNRS5gu35SLtIKE7XLtzQ M5ZOa+WqVAUfkBQZPGg+GTAH+5XLtny353sHlMsJPAv2AyKOkS5SnmZunjxzNoJUUTYAcKj1 oyleuGvWWA0ArFaFBpbEY43VAMDqrd7EYiGusRoAWL1/92I1ALB6U+7FagBg9U7bi9UAwOrt sxerAYCt9oR+plN8SRfXvv1nm4Ye+fCjtyY9ZQ/3FHc8EnlspHzB0x3bcJuRqv8w43iWyOMJ 66f4IfUYiblUs6NNdKvddZAxmR4gfF7P5GnpGW/3TGTI6bpTNaNVz4Qa9PucSWj4ahmiuIGl z5Chrut1bDAX+qN9HZTlgzi9dVB9862Dgi72rYPqm87/pIPqahnb1UFRw3K6kj1VL5LGk9Vr Xxe1Ua+3Lgpj/rgreeuiNjOTg68e2z3PWxe1exw1esUuytfyc8EUf/T21sV27nTtqbqoWMG4 +/F7nFW9jOztoGjV7UkRnNzM7OgfeheewjgWh6t/BgPHG152Rq3hpTdqBY4btIKBPWxd9DrB IHB837f8v8x6zhiDqyrJ+Ci5n0t+M1cmsu98hYaOnlZT5y6MsduWvWnVYW28jefxLZMMhozb k8NTBoEwRqvGyyMhcMjYHAX6r5GQqYJG9ulzwfrOXPA5SXndiAQ6IndpEnPjep5NtuJC7+wv LVT4+ALUO0PzncHDc0KzrlfPtgcwKPVbXcfqtAaBe9H60HN7LbtnBR3PCy6H3cG6Xkv0PAfr dpWpUWZqmHIGX5vqrwGbmv329e+fvn395xVqloa41RcOOMTPIKQNqfzEipsFvfLBByqo2CGd KuCTFMQFoRsIcuhPXOf/AgAA//8DAFBLAwQUAAYACAAAACEAnZjqgWcEAAB0EQAAIQAAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ0LnhtbOxY3Y7iNhS+r9R3sNK7SllCSIBEAyuW GaqVdmdQYR/AJAbScezUNhloVWlfq32cfZIeOzHDMAw/27mpNDchOJ+/4/Od45PjXL1f5xSV RMiMs57TfOc5iLCEpxlb9Jwv05HbdZBUmKWYckZ6zoZI533/xx+uiljS9BPe8JVCwMFkjHvO UqkibjRksiQ5lu94QRg8m3ORYwV/xaKRCvwA3Dlt+J7XbuQ4Y049X5wzn8/nWUKuebLKCVMV iSAUK1i/XGaFtGx5cg5djsX9qnATnhdAMctopjaGdEtT9pyVYHHtkptnieCSz5WeE+c4icuc OihP4o8LxgWeURApL83IWBBJREkGSolstlJE6kfxz5a7OGeFhSZhyjj4VDW1KcCWeuB3s98c ZHBgDILo9CE6yYSmiOEcBqYPHA05U0BjHsliKgjRIFb+IopJMRZmxm05FihLNUM902nUD2qY +csABjeNvekLy4Tj9Vzk/SscQ7DQuudATm30FSbhmKwVSqrB5HE0Wd4dwCbLmwPohjUAK9ga hXQsKo+eu+Nbd6aZogQ1t15VUAxTP/HkXiLGwU/tfuVecltaMu2zpi+WqJZdU9W46qHRw+Il aGrEUusPPN1ox2fwawZxTKWaqA0lRhBYNo6BHC4gP8V64xHmfplodhyr/pBmyT1SHJE0U+gz looIpIwrUrNcgSAK4mFY4AqEsBZrGG4rZV7Wp2X1qZMEjSlOyJLTFAz5ehmQTlaLC9WSf0CS Yzp3ILEg6lbaFyTTDu8lTxB2oFKYDGq2PU/fG11sHgVeqwvjDtLZFIR+GLVbGrGbJToa2gmr ycFgaNu0pE2DxXFK5r9CPPT6/W5lFCh3AHDrH8AGu1gLAGzrANbbxVoAYIPn2OaTNVgAYMNT WAsAbPsU1gIA2zmFtQDAdk9hLQCw0SlsBdBa17tEB8ZsEpiJgGFbSi7fNDppzJ6RBzbNvhWT q8e35oQknKWIkpLQMxjNXjrOOF1m4nxCk+nHCUd8JdTy7CUG1e46Ju0omx8hvKz0BMdKj/Hu 1UqPEd8UaV0MzM3E5KIukHroeelpB9232gNF+632xG+1Z788/u9rT2hrzzVW5EnPY4rg9xee qkNMFZyc9rof07u8XINMp3W0STGtj3kZzqG91736n9GgFQ5vvJE7vAlHbtQKIjca+EP3uutF g6jV6XSanb+cum1NwVWV5WSULVaC3K30gQDeH4caT8h4Y031AzgRNZr+4wsObOtphKVjLLBu k/ba1u/pQts2HCPOdYe724SG+q30XwMyV6KKyO8rLMCCbUlP9KSXBOV1FelYRSY0Swm6XeWz PV3ar6ELnOOB+qA0J96Zl0izzdfQ9wedtt9x262m5w6i4Nr90A26rt9tRl4YRjfD9mCbr1J7 zmB1h9IUyVwNKcHw4aI+FDzm7Levf//07es/r5CzsF3tgRlu9bHapCIVn3FxV5q+Ab51QD4N zVABXzdAFw19hGgO+7Wk/y8AAAD//wMAUEsDBBQABgAIAAAAIQB4AwA50wQAABIRAAAhAAAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1szFhdbuM2EH4v0DsQ6lsBrSVZ/4i9 8DpxWyCbBHX2ALRE28JSlErSqt2iwF6rPc6epDOUZDupi7pJEOTFlsnhN998MyRHvni/LTlp mFRFJUaW+86xCBNZlRdiNbI+3c/s2CJKU5FTXgk2snZMWe/H335zUaeK59d0V200AQyhUjqy 1lrX6WCgsjUrqXpX1UzA3LKSJdXwU64GuaS/AnbJB57jhIOSFsLq1stz1lfLZZGxyyrblEzo FkQyTjXwV+uiVj1amZ0DV1L5eVPbWVXWALEoeKF3BnQP04ysjRRpF5JdFpmsVLXUuCYtaZY2 JbdImaU/rUQl6YKDSGVjRu4kU0w2bKK1LBYbzRROpd/32PU5DGsEEdoE+FA1vavBl2LZj4zm FjGG4A2yaI0hPdmc50TQEgbmLEN9CBoyaWZVfS8ZQzvR/CDreX0nzaKb5k6SIkeQbrE16CY6 M/NTgBk8DB4tX/VINN0uZTm+oCkkjGxHFtTVDj9hEU3ZVpOsHcwOo9n69oRttr46YT3oHQCD vVMoybqN6J/heH0494XmjLj7qFpTCkuvq+yzIqKCODH8NrzspunBMGaEr9eklV4jVGfXTho9 entlNO2J7pWIPG/oDo0cvu+EifNIlCiKPB8GCUrjDkPPiQLjpEcCJy10nerthyrfoaQL+IbM UZGtK9hIGlfQlCs91zsOeYbnhrvAiFC+gp3OoQpomrPlzzCkfhtZ4BJ8LkziMwoKUM47t91K SPdDRBCbpiAJfAAIp3hkMGF/mrfO9XjKi+wz0RVheaHJR6o0k8SoBmcK0EJAbWABBZ4BEILr gzJxouD/nlWQsa3weyypO04ztq441DjxkANsgj59T0owimrBboBS7evhSXn2EieMIOcPiv9h ngPHceOoE7zdO+fkedFinsozHG3XZt8VIocDBB8xVYvNDRzkhslR9uEwbqdVxYt8VnCOtubQ Y1MuSUM5FNUWTxZIWSF0OxIBbVO+kLy9sUnlEQ7MtZ7MxL6YTEV6WJEtUz+IgAXIfQZdN35F usgRwwbmwwPdxIXdey7d8BXpIseOrn+g6w4jF1mcJy9GZgrgFaoBSXZ8gyO+sRdjkt8eXyTZ 8Q0PfD0vBnnfIl8k2fGNjvhG/vD87faa9YAkO77xgS+SPX+/vSZfJNnxTY74hkH0NvcbkmxP 4qPmwFzlyB4OuX2bZsL6X1c73sLmZlfPvtr9/mq/pJo9uNrNPfrcqz3X8F4Dbc+a8mV/xbc3 Gba0RiF8mBux2obLNBR9c9J3XOYi7a9f88NIuYTeG7vo35PJMJheOTN7ehXM7GToJ3Yy8ab2 Zewkk2QITYAb/WF1DWUOoeqiZLNitZHsdqMtLKyTGQBexpse+/C+MnC9g+DgG5cxkd9RSbG/ e9SaPaXTCvp0zKoKu7jjXsvHJuS5CVlq2Wbklw2V4KFPyn80XsbzmUl5WUXCXpE5dEyM3GzK xSNdTNv+XF3gLRugT0pjelzoEl+yXgPPm0ShF9nh0HXsSeJf2h9iP7a92E2cIEiupuFkX68K IxfA7lSZElXqKWcUXja6N5xDzX798ud3X7/89QI1a5rk9lUWHvGd15Qilx9pfduYEwz+iYB6 gi4Whmr47wFKBk0PJojR/5cx/hsAAP//AwBQSwMEFAAGAAgAAAAhAJZ+OZSbAwAA/woAACEA AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWysVtuO2zYQfS/QfyDUtwKKbPkq Ye3A8a6LAsmuUW8+gKYoi11eVJJS7BYF8lvt5+RLOqQkb5M4C+/GL7JMzZyZOXM45NXrveCo ptowJWdB/1UvQFQSlTG5mwXv71fhNEDGYplhriSdBQdqgtfzH3+4KlPDs7f4oCqLAEOaFM+C wtoyjSJDCiqweaVKKuFbrrTAFv7qXZRp/AGwBY/iXm8cCcxk0Prrc/xVnjNCrxWpBJW2AdGU Ywv5m4KVpkMT5Bw4gfVDVYZEiRIgtowze/CgR5h6FlRapm1JoWBEK6Ny63xSgUlaCx4gQdJf d1JpvOVAkqj9ylpTQ3VNF9Zqtq0sNe5T+nOHXZ6TYelApPUFfs6aPZQQS21/D5A3gkjQwWAO rSEbniGJBSzcM8spggaipZIWkLyBKe81pc5U1r/oclOutfe7rdcasczhtP5B1H5ozfxfCWbw En3hvuuQcLrPtZhf4RT6hfazAGR1cE9wwindW0SaRfK4Soq7E7akuDlhHXUBIINjUFBk2VT0 dTlxV05DR/9YVWOKwfWtIg8GSQV1uvKb8sht3YG5mh18WaCGeeuYbe2aj56Pzt4Ap54su3+j soMrfAu/fhGn3NiNPXDqCYG0cQrg8AD6OXZ7j8rw/cah49TOl5yRB2QVohmz6B02lmrk48Pm BJQrIMRCPzwKPAEQcukCw2vDzLf5GXT8tCJBa44JLRTPIFDs0gBRdVw8ky2WQa87Qi9AFPCK eM2Pcno+cU6AnjdzgjjPHjy6KD7zp9uzoUTBBuO0pvwMRM/n04j3BdPnAw4anTxFxEpV2hZn pzg8A5HlTwA+T37DTn7X2NLPtOdLe7n2mp2aWTjE/oRpi3kewHhzevSzyG9Yt639y0t3bg7D 1s3Mv5LFYLS86a3C5c1oFSaDYRImi3gZXk97ySIZTCaT/uTvoB0fGZRqmaArtqs0vavcYP7G AGgmidviQzicon78KDKI7dyozNZY49++Hh8vmQajrh0rpdyk+f8w8Mr43obkVjcd+aPCGiJ0 TbnglLgsI+OOkQ1nGUW3ldh+wcvo+4ZkI1S4UgH0SWr80LiwXkdxvJiM40k4HvR74SIZXodv psNpGE/7SW80Sm6W48VRr8ZVLiG7UzJFRtglpxjukO0h/6jZTx//+enTx38voFkov7u4wKu7 5Phziet3uLyr/fiDayfoaemXSrhowsnlTB9NHEZ3cZ3/BwAA//8DAFBLAwQUAAYACAAAACEA ToacmIUEAACIEAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbMxY227j NhB9L9B/INS3Al7raslC7IXXiYsC2SRYZz+AlmhbCHUpRal2iwL7W+3n7JfsDClaTuq2QeoH vziUNDw8c2aGHObq/S7npGWizspiYjnvbIuwIinTrNhMrM+Pi0FkkVrSIqW8LNjE2rPaej/9 /rurKq55ekv3ZSMJYBR1TCfWVsoqHg7rZMtyWr8rK1bAt3UpcirhUWyGqaC/AnbOh65tj4Y5 zQqrmy9eM79cr7OEXZdJk7NCahDBOJXAv95mVW3Q8uQ1cDkVT001SMq8AohVxjO5V6AHmHZi NaKIO5cGeZaIsi7XEufEOU3iNucWyZP4501RCrriIFLeqjcPgtVMtGwmpchWjWQ1fop/NNjV axhWCFJI5eBz1eS+grVkJjmziDKDtSCG1hSCkyx5Sgqaw4tHtCBLnqVMfaqrR8EYGhXtT6Ja Vg9CzbhrHwTJUkToZlrD7kNnph4LMIPB8MX0jUGi8W4t8ukVjSFWZDexIKX2+AuTaMx2kiT6 ZdK/Tbb3J2yT7c0J66FZABgcFoVsrLRHf3fHNe5oIZyDV9qUwtTbMnmqSVGCn+i+di+5aw0Y +ozw1ZZo1RMpFFpnqr8rScyUWslquB7EGEVBZGtFXMezfTd4rksYhq6PBqiO44e2rS2OvdbQ VSx3H8p0j6qu4K+KCo15LZdyz5lSGzShMTCHH4gtp1jUrBh8XupF5XTOs+SJyJKwNJPkI60l E0SqhKkR5QrWlRBshQK/AAhemoVhqGX/Z/E9I/6yWWlcF9eGBDXqvkn/ullp/SFhIZtMyF4f B8cLnVEXCC+KRrAbPQ/ECKKgIqUCEQYuWmNimJAq53VaGD1OBgLV5y13IB8IbDe3qiCyIoWi VkPKN7DzQkJBcQJAcwf7rApeytafEB8EKqF4Fxnn6gE3VzbngrSUQ/3vsOAhSlkh9ZswsA9U 1baFxor4EQ64YfBh2PFDHBi6PVU/CFEZcnl8kWTH1+v5jh1fVc/l8UWSHV+/53tIw8sjjCw7 wsER4ciNVFlcHmFk2REe9YRdN4LKvcgURpYd4fCIcOh7F1pzyLIjHPWEke2FFh2y7AiPjwiP glDt/ZeXw8hSbdXmGEf2bzvF4Yg850Hum4P8mkpGHjhN2LbkKbQL3jkO9FTCPeM3aIgpX8Nx ow51fd5in6lEwcFS6YNth2p3+lbk5NHb90Br6Iaxtf19PPOC+Y29GMxvgsVg7PnjwXjmzgfX kT2ejT1ov5zwD6vr8lJwVWY5W2SbRrD7RloYjpOtlOaDzZIP94eh4/adE6yN01iRPlBB4Uh/ 2Yi9pa8KTDgWZYk923FA/HMEZA0NiYrILw0VsIIJyn+0Wqq3+9d+qA/KeRUZGUXUTYfcNfnq hS6q1f7fnSdPAfqkNKqzVZeA8+Wrb/u+5wXeYDZz/cH4g+8PZteeC/kaOov5fDHzbqJDvtZ4 xyuAXZemWuruYiCnX7/8+cPXL3+dITNV76tvkTDEu6Zq6bn4SKv7Vm25cP+HrIHOE15VcOMH LmjamyCG+Q/C9BsAAAD//wMAUEsDBBQABgAIAAAAIQAncAJpCAUAAOoRAAAhAAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDkueG1srJjrbts2FMe/D9g7ENq3AaotWXfELlwnGQqk iTGnD0BLtC2EuoyiXXvDgL7W9jh9kp1DibaVOqvj6EsiS4c/8tz+pHT1fptxsmGiSot8aFjv +gZheVwkab4cGp8fb83AIJWkeUJ5kbOhsWOV8X70809XZVTx5I7uirUkwMiriA6NlZRl1OtV 8YpltHpXlCyHZ4tCZFTCT7HsJYJ+AXbGe3a/7/UymuZGM16cM75YLNKYXRfxOmO5rCGCcSph /dUqLStNy+JzcBkVT+vSjIusBMQ85ancKegesxkaa5FHjUtmlsaiqIqFxDFRRuNok3GDZHH0 cZkXgs45BCnbqDtTwSomNmwspUjna8kqfBT9qtnlOSssEZJL5WA7anJXwlxlGj9uDaLMYC7I oTGC5MQznpCcZnBjmsZyLRj5ksoVmdASQ6VsqvJRMIbW+eY3Uc7KqVBD7zdTQdIEUQ3C6DUP GjP1MwczuOg9G77UJBptFyIbXdEIkka2QwNqa4d/YRCN2FaSuL4ZH+7Gq4cTtvHq5oR1T08A K9hPCmVZ1h59746t3XlMJWfE2ntVm1IYelfETxXJC/AT3a/di+83GoY+I75ckTr8ElGNXf1Q xUPbVyqmeqH7SFh+aNsBtBZ47gTQCP1nUXGdwHPgJsHYuJ7nDwI1iSbBJDW6jOT2Q5HsMKRz +A+Zo3m8KqCZ5jiCRrySM7njkGe43nALVkQoX0K3c6gCGiVs8Tvcqv4cGtCSMOVce763hyS3 ORBiGkEg4A8M5RTFguXm51k9pRxNeBo/EVkQlqSSfKKVZIKoWIGawGIQKBUWKHANQHBJu6K8 wzC/nMuBzqWu7imnMVsVPIGJbFwG9IDO20WZhcYyoAugRHUdXJZfz7J9360Do4u+lV7HsrAG 0OK4pF/K74tJBS27U02W5gkoBl5ihubre1BuNeoo1QPIdTNjUxRoC5c21keNclwfrcg5PPvg QQNpeIMDL7QcVdNn8dCyjgjwENLwnAPPGvgWds55C8Ta3gOR0gDdI2AATXkZECkN0DsAoclh gRetECkN0D8C+o7K3AUuI6UBBgcg0s5PSiuGSGmA4RHQc/0Lk4IU1QPHkqWkhuXJlAqKOvVM bC7RDkdrxyP247FwDLBC3iocKMNwaAI9XVG+aDRESZLaGpSPuGfOlLtayLWyn9wj3AHsAPUW cNg5WyIS9GHHqCfRpP/ZI5QaHEe50YCm8c8sWKvVo7ixNOVwoYZYLU1CSMO7UEOsVrl2oCFh xxLS4nWgIC1eBwLS4nWgHy1eB/LR4r2sHlBIBAp8f/RUZfWqgwvqhDq3VG8+uLhafK6pZC3x cboQn0R+Jz1Wve+h5JzUHiV5+uilT5EthVA/lBAv4K0C3wz+CscDd3LTvzUnN+6tGQ6c0AzH 9sS8DvrhOBz4vm/5fxvNITkBV2Wasdt0CS8iD2tpYGOfzADkSs0mRw68h/Us+xBwmBuHdbsX eDodt0WBZ9Tj3UAd2t66GyykqDPyx5oKmEGfKX9wqHxNUrqNiK8jMuNpwsj9Ops/i4vXRaHC 1wNAnwzND/bK14RmX6+ubY99z/ZNb2D1zXHoXJsfAicw7cAK+64b3ky88b5eK/Q8h9WdKlNS ZXLCGYUXKNVY8PKyr9lvX//55dvXfzuoWbV516/ncIlv8+pgwsUnWj5slILBFxaop4m6VcI3 FYgLmh5MkKG/0Yz+AwAA//8DAFBLAwQUAAYACAAAACEAUFG7YCsFAAAeEgAAIQAAAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQ4LnhtbMRYW27jNhT9L9A9EOpfAY2t9wOxBx4nKQpk kqD2LICWaFsNJaoU7bFbFJhttcuZlfSSEv3QeGI5CdAfR5EOD+/zXEpX7zc5RWvCq4wVA8N6 1zcQKRKWZsViYHya3pqhgSqBixRTVpCBsSWV8X744w9XZVzR9A5v2Uog4CiqGA+MpRBl3OtV yZLkuHrHSlLAsznjORbwL1/0Uo4/A3dOe3a/7/dynBVGs553Wc/m8ywh1yxZ5aQQNQknFAuw v1pmZaXZ8qQLXY7506o0E5aXQDHLaCa2inRHsx4YK17EjUtmniWcVWwu5Jo4x0m8zqmB8iT+ dVEwjmcUgpSv1Z1HTirC12QkBM9mK0Eq+Sj+WXOXXSwsJUkhlIPHURPbEvZis9+nGwMpGOwF OTSGkJxkQlNU4BxujFkhgAF9zsQSjXEpQ6UwVTnlhEh0sf6Fl5Pykaul9+tHjrJUUjUURq95 0MDUvwXA4KLXWr7QTDjezHk+vMIxJA1tBgbU1lb+wiIck41ASX0z2d9Nlg8nsMny5gS6pzcA C3abQlmWtUffumNrd6aZoARZO69qKIaldyx5qlDBwE/pfu1ecr/WZNJnSV8uUR1+IakaXP1Q xUPjKxVTbeguEq4XQPmrcNiB0/daMXH6/dCxHAPJyFiWbzeIQ49r5jIWmw8s3cqIzuAvJA4X yZJBL83qONNKTMSWQppxTNfUAoMQpgtodgpFgOOUzH+DW9WfAwNMAptm2vEdHnIM1wc8EGEc QxzgB5ZSLLWCFOanSb2lGI5pljwhwRBJM4E+4koQjlSoQEzAGEkoFC2wwDUQQti0K3BZJ/H7 qYTYHBf3I8UJWTKawka2NANaQKftwsRmKZSlzn33nDpe4Mk8yRo/lVTPsixA1En1Qs+xIMOy wHR1KLfr8tKR0ElVHXOYgSaTrQQ6sqhqygMAXNpNGR4mOzzEagBgnRNY9xCrAYB1T2BlEe1s 0ADAeuewGgBY/xxWAwAbnMNqAGDDc1gNAGx0DlsDTrUGrETAsNO6y1tFqqPqlOpEq6h+gR+9 i6rV5xtyQhJWpIiSNaEdGFUHPc84XWa8O6Gq9OcJb9mKw4DqaqIri+wMYzZ/hvAywXG14Exl ag7VRrn2crWpx4jUbjhogQgvMZ0bMH1Bg1QWwMzuGnQwVyzX8ay6FffD9miwuH5k9f1XaxCC M9SdGu5ZkcI5Q17KzMxW93BiVEk6kB3rSErkNJJYaBapQA2V9qIT35HktWSs4YssV+6KOvEd yVdL6ho+ywksvyth9Iwcar7QDqUadzLwiK8lmQ2fbYdg3kv4WrKq+QJXTZbL7WtJb8MnyTon 5MjfljxrPt8LXpaP/03CLxMfT4vPNRbkSHyUCr5WfFLxjfRY9Qz/rvZAW+/PaydPKarx1UFx Dm8i8m3ir2jkeOOb/q05vvFuzchxIzMa2WPzOuxHo8gJgsAK/jaag3UKroosJ7fZYsXJw0oo UTl53gTlULuJoQvvbj3L3k842FvqCynSR8yxPOi2TqsvOXz6Oh23jMmD7eE08ORYem1C5oLX GfljhTns0MwD68yh9JKkvG1EAh2RCc1Sgu5X+awVF/8t4gJfHID6ZGjOzMpLQrOrV8+2R4Fv B6bvWH1zFLnX5ofQDU07tKK+50U3Y3+0q9dKel6AdepU0io0VOViTAmGt67mVW9fs1+//PPT 1y//vkHNqheI+pUeLuUXAFWKlH/E5cNaDVr4KgP1NFa3SvgOA3GR0D1EcujvOsP/AAAA//8D AFBLAwQUAAYACAAAACEAj499ivgDAAAWDAAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQxMS54bWy0VtFu2zYUfR/QfyC0twGqZdmyLSF24TrxMKBNjNntO03RNhGK1EhKtTcM 6G+1n9Mv2SVlOk3iZE6TvsiWdHnuveccXfLszbbgqKZKMymGQft1FCAqiMyZWA+DD4tpOAiQ NljkmEtBh8GO6uDN6NUvZ2Wmef4O72RlEGAIneFhsDGmzFotTTa0wPq1LKmAdyupCmzgVq1b ucKfALvgrTiKeq0CMxHs16tT1svVihF6LklVUGEaEEU5NlC/3rBSe7SCnAJXYHVdlSGRRQkQ S8aZ2TnQA0w9DColsn1LYcGIklqujF2TFZhkdcEDVJDsj7WQCi85kFTU7slMUU1VTcfGKLas DNX2Vfabxy5PqbC0IMK4Bm+zZnYl5ALtzIIZTsciX2wD5OIhKYgZjEAlMuc5EriABx8hlBHM kYtHICpa0K1xYbpcKErtAlH/rsp5OVNu9WU9U4jlFm2PErT2L/Zh7lZAGPxp3Vm+9kg4265U MTrDGQiItsMAfLazV1iEMygCkeYhuXlKNldHYsnm4kh0yyeACg5JwaJl09H9dmLfzh1S2of2 mjUYMN5Jcq2RkNCw5aHpk1zWHtU2b/OUG9RoYqweAZKKgXKNRPtVTaijya/Wjmpf/4GgXi9O u1FDU9zv9jqD21zFUdJ37y1jySBpJ3HikngkSNJAl5nZvpX5zjK9hF8Q1JpmGFBsm29guTZz s+PU6QGs4QxaggsEc2xnARXhh3kTa0YTzsg1MhLRnBn0HmtDFXJdw7AAlDPQw4AdHApcARDK 8WW4yixhD8vTuS+PNcmMY0I3kueQLrbFgL+9Dj+klOXjjlDgdrCil/l0wbpJH0aas/UxvXpR Ox3Y9z9LL7AR4jU/fFRP188y7OTTR/RzIsLFZ3EEPe6SOSUSZgynNeUnIDpBH0dcbJg6HbDT 2PUxIqayUmZzcondExDZ6hHAp30FXf8VnGNDb5nftfZc8+cG9va/YRPCfBXsbe8mMlT5gO/d J+e/Yz9O3My4P0BWsPHYneOfdNxJJhfRNJxcJNMw7XTTMB3Hk/B8EKXjtNPv99v9f4P97Myh VcMKOmXrStGrym5PD8wh8KJLbUZd2LNb7fjGZJDbLqMin2GF/7w/xX5kKCVejqmUduB9P42c M54ryMqoRpG/Kqwggxflf4bRU0R5WUZ6npE5ZzlFl1WxvMOL25OeywucNAH6KDVuaLywX5M4 Hvd7cT/sddpROE675+HbQXcQxoN2GiVJejHpjQ9+1bZzAdUdsynShZlwiuFovT/q3Hj22+cv v377/PUFPOv20+b4Bn/tgc9tjFy9x+VV7cYfnMbBTxP3qITzN1jGht6EWAx/nh/9BwAA//8D AFBLAwQUAAYACAAAACEA+18rCScBAABjCAAALAAAAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMv c2xpZGVNYXN0ZXIxLnhtbC5yZWxzxJbNasQgFIX3hb6D3H1jzMxkfhgzm1IY6KpMH0DizQ9N NKhTmrevDBQSaC0DATeCVzz38xxQj6evviOfaGyrFQeWpEBQlVq2qubwfnl52gGxTigpOq2Q w4gWTsXjw/ENO+H8Jtu0gyVeRVkOjXPDgVJbNtgLm+gBlV+ptOmF81NT00GUH6JGmqVpTs1U A4qZJjlLDuYsGQNyGQff+n9xXVVtic+6vPao3C89qO1aia9i1FfnZYWp0XFIkmndTieMJf4A QP9gy6KyZUG21ZJszgeKM8duFXobwx4tiXF3fCGHooYXzG7R6O71bBXybB0zzXWIbBOTbBMi y2OS5SGybUyybYjMvzrxLv1diGwfk2wfImP+7Y5nGkt/2Ojsa1B8AwAA//8DAFBLAwQUAAYA CAAAACEATIAUOrQDAAA2CwAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54 bWysVttu2zgQfV+g/0CobwVU+W5LiF24TrxYoE2MtbvvNEXZRHhRSUq1d7FAf2v3c/olO6RM Z9O4gZPmRZap4ZmZM0dHvHi3ExzVVBum5Dhqv21FiEqiciY34+jTah6PImQsljnmStJxtKcm ejd59ctFmRmef8B7VVkEGNJkeBxtrS2zJDFkSwU2b1VJJTwrlBbYwl+9SXKNvwC24Emn1Rok AjMZHfbrc/aromCEXipSCSptA6IpxxbqN1tWmoAmyDlwAuvbqoyJEiVArBlndu9BjzD1OKq0 zA4txYIRrYwqrNuTCUyyWvAICZL9tpFK4zUHkkTtVxaaGqprOrVWs3VlqXGPsjcBuzynwtKB SOsbvM+a3ZeQC2ZnV7sI+ThIBkOMJjAdsuQ5kljAwopZThHMEP0BwYxgjlZ0Z32YKVeaUrdB 1r/qclkutN99XS80YrlDO6BEyeHBIcz/lRAGN8l32zcBCWe7QovJBc5gcGg3jkBfe3eFTTiD IhBpFsndKtnenIgl26sT0UlIABUck4I0y6ajh+10QjsNKe1jV00ohq0fFLk1SCro07XftEeu 6wDmenbw5RY1I7CO30Nc89DzEeINcOrJsrv3Kt+7xtfw6xdxxo1d2j2nnhAoG2cADhegn2P3 ElIZf1o6dJzZyYwzcousQjRnFn3ExlKNfH54SwHlAgixMA+PAlcAhFpCYrhtmPkxP93Azz2p oAXHhG4VzyFdxxUDAguMPIszx0CElGag7UbEEcgNtBAIfwqRzsAAhWJXdEPVQ1phCojX/Ci+ p9Ps5OpZNido9lzDJWTxfTw+zCUlCl5KTmvKz0D0vD+OuNoyfT5gt6HqMSLmqtJ2e3aJvTMQ WfEI4NPE2gtivcSW3tOob+1nNZpb+Pb9CSaNeRHU6Z3Lv97OBPzNc9/zAgzaOexf6bTbn121 5vHsqj+P024vjdNpZxZfjlrpNO0Oh8P28O/oYDY5tGqZoHO2qTS9qZyN/8AuGt9xhtCDb1rS 7tyJDHK7bVTmC6zx7w/N5jne0Q/jmCvlfOn/puGV8bMDKaxuJvK5whoyhKE8xzO8oT50iZdl ZBAYWXKWU3RdifV3vPRfwkzhJAbQJ6nxpvHCeu13OtPhoDOMB912K56mvcv4/ag3ijujdtrq 99Or2WB61KtxnUuo7pRMkRF2ximGo+fhSHCn2W9f/3n97eu/L6BZaD8cc+DWHYz894vrj7i8 qb39wWkV9DTzSyWcT0EdLvQuxGGE8+7kPwAAAP//AwBQSwMEFAAGAAgAAAAhACkLWyDTAwAA iwoAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTIueG1srFbbjts2EH0v0H8g 1Je2gOP7TVhvEHvXQYDNxqg3H0BTtC0sbyUpxW5RIL/Vfk6+pDOUaLeOgzUCv9gUOTycOTNz yJvXOylIya3LtZok7VethHDFdJarzST5+DRvjBLiPFUZFVrxSbLnLnl9++MPNyZ1Inuge114 AhjKpXSSbL03abPp2JZL6l5pwxWsrbWV1MOn3TQzSz8BthTNTqs1aEqaq6Teby/Zr9frnPE7 zQrJla9ALBfUg/9umxsX0SS7BE5S+1yYBtPSAMQqF7nfB9ADTDlJCqvSOqSGzJnVTq897kkl ZWkpRUIkS99tlLZ0JYAkWYaZheWO25K/8d7mq8Jzh0vprxHbXOKhQRDlQ4D/Z60A8DugE/OW 3EJC2FJkRFEJHswK57UkVX7CojNPlnM0U+Vba5ZmYcOex3JhSZ4hRr03adYLtVn4VGAGg+bJ 9k1EoulubeXtDU0hQ2Q3SaCQ9vgLm2jKd56wapIdZ9n2wxlbtr0/Y92MB4AHh0OhBk0V0dfh dGI4T7kXnLQPUVWmFLY+aPbsiNIQJ4ZfhcceywiGMSO82RK/N8CqR6jarloMfER7B5wGsvxu qrM9Br6C/zBJU+H80u8FD4SA2zQFcPgB+gXFbuOq8XEJ3Sb9THAKWa3J87czkbNn4jXhWe7J e+o8tyQ4A70JkDfAjofk1JBcZQtq6W8nyBgfTeFkcDp6CMOKwm8T2Y1EzrXGcxeCMr7VIoNx 5xqsrr2FqP+YJL8X1MIJCZQj1Eo7hB8IxjR8xTSSd1Jzvf4QVCUU3qA3HLZgHNiO5dcZjfsD NMAi7A767U4/ZPMIZKzzbzl0Dg4mieXMJ3gQLR+crwmsTYJLmHIskcjn1TKuzd7mm60nP7Nf CAQ1JguQTfIuAy0AjSIzbQ3IDcreZdknWW597L3vqYNerIOlyDNOHgu5OqmG7jWqAW4VgD5b ELFFr9B6a1BKFL0/R63RtDedzxvzcavbmM16d43Rm9l9YzodDLv3nfvxdNj9K6n732HkCry7 rHErOcDW/PL575++fP7nmCk4HzGu26lwVVfq/4QF/98+HV4jM6hlZ/MS8v69jdoftLu900Yd dTrjQ6MOB1D/lRjERg2ydUHnIceiFG3IBKFiA5rKQGxwdlU8wnsmqEPG1yiVqEDtcGgeb4PD 5hqnE7r9zOZKGeCkaAHD7ovG0QKMey8aVxbQuPEeQZ/CNYLBAcThvgBBOnOtHNr/5QvmWKYA 9S2pCCmonhQwxKdHeDUI+56aD2XwAZ6AIOezMGVAvZAlMD2aIEZ8RN7+CwAA//8DAFBLAwQU AAYACAAAACEAxBOwZgEHAACTHQAAFAAAAHBwdC90aGVtZS90aGVtZTEueG1s7FnNbxtFFL8j 8T+M9t7GTpw0iepUsWM30KaNEreox/Hu2DvN7M5qZpzEN9QekZAQBXFB4sYBAZVaiUv5awJF UKT+C7yZ2V3vxOPGCeFD0Bxa7+zvvXnv9z7mY6/fOE4YOiRCUp42g/rVWoBIGvKIpsNmcK/X vbIaIKlwGmHGU9IMxkQGNzbefec6XlcxSQgC+VSu42YQK5WtLyzIEIaxvMozksK7ARcJVvAo hguRwEegN2ELi7XaykKCaRqgFCeg9u5gQEOCelplsFEo7zB4TJXUAyET+1o1cSQMNjqoa4Qc yzYT6BCzZgDzRPyoR45VgBiWCl40g5r5CxY2ri/g9VyIqRmyFbmu+cvlcoHoYNHMKYb9ctJ6 t7F2bavUbwBMTeM6nU67Uy/1GQAOQ/DU2lLV2eiu1luFzgrI/pzW3a4t1xouvqJ/acrmtVar tbyW22KVGpD92ZjCr9ZWGpuLDt6ALH55Ct9obbbbKw7egCx+ZQrfvba20nDxBhQzmh5MoXVA u91cewkZcLbtha8CfLWWwycoyIYyu/QUA56qWbmW4IdcdAGggQwrmiI1zsgAh5DFbcxoX1A9 AV4nuPLGDoVyakjPhWQoaKaawfsZhoqY6Hv94tvXL56h1y+enjx6fvLoh5PHj08efW91OYLb OB1WBV99/cnvX36Ifnv21asnn/nxsor/+buPfvrxUz8QKmhi0cvPn/7y/OnLLz7+9ZsnHvim wP0qvEcTItEdcoT2eAK+GWJcy0lfnE+iF2NaldhMhxKnWM/i0d9RsYO+M8YMe3At4jJ4X0AH 8QFvjh46Bu/HYqTykDue3YoTB7jDOWtx4WXhlp6rQnNvlA79k4tRFbeH8aFv7jZOnfh2Rhm0 TupT2Y6JY+Yuw6nCQ5IShfQ7fkCIh68HlDq87tBQcMkHCj2gqIWpl5Ie7TvZNBHapgnEZewz EOLtcLNzH7U483m9RQ5dJFQFZh7je4Q5NN7EI4UTn8oeTliV8NtYxT4j98cirOI6UkGkh4Rx 1ImIlD6ZuwL8rQT9FnQPf9h32DhxkULRA5/O25jzKnKLH7RjnGQ+7D5N4yr2PXkAKYrRLlc+ +A53K0Q/QxxwOjPc9ylxwn12N7hHh45JkwTRb0ZCxxK6tdOEE5q+7chzd+RNQb0lsX2qD8/C ne6+bS4i+u9vvlt4lO4SyPfpFeht733be4P/fO+dVc/zdtxJk4X+q/c5doNstsvJzN3ygDK2 r8aM3JZmwyxhwYi6MKjlzEmRlKenLIafeYN3cEOBjQwSXH1AVbwf4ww22/VAKxnKXPVQooxL OOSZYa9ujYcNu7JHxGV9eLD9QGK1wyM7vKSHizNCqcYsO0NzEC0mWtIK5p1s6VquFNy+yGR1 bdTcs9WNaabVObOVLkMMp12DwZJN2Ikg2L8AyytwVtdTwyEFMxJp3u0iXITFROGvCVHutXUk xhGxIXKGK2zWTeyKFDKXBZBSntCdj82SNSDtbCNMWszOnzlJLhRMSNZld6qaWFqtLZaio2aw try4HKAQZ81gAMdT+JlkEDSp926YDeGOJ1TCZu2ZtWiKdOLxmj+r6nDjMKNgnDLOhFRbWMY2 huZVHiqW6pms/YvLDZ1sl+OATdQLWLG0Cinyj1kBoXZDSwYDEqpqsCsjmjv7mHdCPlJE7MfR EeqzkdjDEH7gVPsTUQm3DKag9QNciWm2zSu3t+adpnoRZXB2HLMsxnm31FcqRcVZuKm30gbz VDEPfPPabpw7vyu64i/LlWoa/89c0csBnPiXIh2BEG5kBUa6XpsBFyrm0IWymIZdAeu+6R2Q LXCtCq+BfLgXNv8Lcqj/tzVndZiyhoOb2qNDJCgsJyoWhOxCWzLZd4ayer70WJUsV2QyqmKu zKzZfXJIWE/3wBXdgwMUQ6qbbpK3AYM7nX/uc15B/aHeo1Trzekh5dJpa+Dv3rjYYganTu0l dP4W/JcmelY/K2/EizWy6oh+MdklNYqqcBa/tbV8qguaMM8CXFlrbcea8nhxuTAOojjtMQyW +5kM7m2Q/gfWPypCZj8y6AW1x/egtyL4ZmD5Q5DVV3RXgwzSDdL+6sO+xw7aZNKqLLX5zkez VizWl7xRLec9Rba2bJ54n5PschPlTufU4mWSnTPscG3HZlINkT1dojA0KM4hJjDm61T1AxLv P4RAb8FV/YjZT0oygydTB9muMNnV59E4/8mkXXBt1ukzjEaydI8MEI2Oi/NHyYQtIftZo9gi G7QW04lWCi75Dg2uYI7Xona1LIUXzxYuJczM0LJLYXNV5lMAH7Xyxq2PdoC3TdZ6rYurYIql f4ayOYz3U+Y9+cxLmT0ovjFQF6BMHb+ZspwpIG868eCzpMBwNNk3/RcWHZvpJmU3/gAAAP// AwBQSwMECgAAAAAAAAAhALJKQC7WIAAA1iAAABcAAABkb2NQcm9wcy90aHVtYm5haWwuanBl Z//Y/+AAEEpGSUYAAQEBAEgASAAA/+IFQElDQ19QUk9GSUxFAAEBAAAFMGFwcGwCIAAAbW50 clJHQiBYWVogB9kAAgAZAAsAGgALYWNzcEFQUEwAAAAAYXBwbAAAAAAAAAAAAAAAAAAAAAAA APbWAAEAAAAA0y1hcHBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAALZHNjbQAAAQgAAALyZGVzYwAAA/wAAABvZ1hZWgAABGwAAAAUd3RwdAAABIAA AAAUclhZWgAABJQAAAAUYlhZWgAABKgAAAAUclRSQwAABLwAAAAOY3BydAAABMwAAAA4Y2hh ZAAABQQAAAAsZ1RSQwAABLwAAAAOYlRSQwAABLwAAAAObWx1YwAAAAAAAAARAAAADGVuVVMA AAAmAAACfmVzRVMAAAAmAAABgmRhREsAAAAuAAAB6mRlREUAAAAsAAABqGZpRkkAAAAoAAAA 3GZyRlUAAAAoAAABKml0SVQAAAAoAAACVm5sTkwAAAAoAAACGG5iTk8AAAAmAAABBHB0QlIA AAAmAAABgnN2U0UAAAAmAAABBGphSlAAAAAaAAABUmtvS1IAAAAWAAACQHpoVFcAAAAWAAAB bHpoQ04AAAAWAAAB1HJ1UlUAAAAiAAACpHBsUEwAAAAsAAACxgBZAGwAZQBpAG4AZQBuACAA UgBHAEIALQBwAHIAbwBmAGkAaQBsAGkARwBlAG4AZQByAGkAcwBrACAAUgBHAEIALQBwAHIA bwBmAGkAbABQAHIAbwBmAGkAbAAgAEcA6QBuAOkAcgBpAHEAdQBlACAAUgBWAEJOAIIsACAA UgBHAEIAIDDXMO0w1TChMKQw65AadSgAIABSAEcAQgAggnJfaWPPj/AAUABlAHIAZgBpAGwA IABSAEcAQgAgAEcAZQBuAOkAcgBpAGMAbwBBAGwAbABnAGUAbQBlAGkAbgBlAHMAIABSAEcA QgAtAFAAcgBvAGYAaQBsZm6QGgAgAFIARwBCACBjz4/wZYdO9gBHAGUAbgBlAHIAZQBsACAA UgBHAEIALQBiAGUAcwBrAHIAaQB2AGUAbABzAGUAQQBsAGcAZQBtAGUAZQBuACAAUgBHAEIA LQBwAHIAbwBmAGkAZQBsx3y8GAAgAFIARwBCACDVBLhc0wzHfABQAHIAbwBmAGkAbABvACAA UgBHAEIAIABHAGUAbgBlAHIAaQBjAG8ARwBlAG4AZQByAGkAYwAgAFIARwBCACAAUAByAG8A ZgBpAGwAZQQeBDEESQQ4BDkAIAQ/BEAEPgREBDgEOwRMACAAUgBHAEIAVQBuAGkAdwBlAHIA cwBhAGwAbgB5ACAAcAByAG8AZgBpAGwAIABSAEcAQgAAZGVzYwAAAAAAAAAUR2VuZXJpYyBS R0IgUHJvZmlsZQAAAAAAAAAAAAAAFEdlbmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABadQAArHMA ABc0WFlaIAAAAAAAAPNSAAEAAAABFs9YWVogAAAAAAAAdE0AAD3uAAAD0FhZWiAAAAAAAAAo GgAAFZ8AALg2Y3VydgAAAAAAAAABAc0AAHRleHQAAAAAQ29weXJpZ2h0IDIwMDcgQXBwbGUg SW5jLiwgYWxsIHJpZ2h0cyByZXNlcnZlZC4Ac2YzMgAAAAAAAQxCAAAF3v//8yYAAAeSAAD9 kf//+6L///2jAAAD3AAAwGz/4QB0RXhpZgAATU0AKgAAAAgABAEaAAUAAAABAAAAPgEbAAUA AAABAAAARgEoAAMAAAABAAIAAIdpAAQAAAABAAAATgAAAAAAAABIAAAAAQAAAEgAAAABAAKg AgAEAAAAAQAAAQCgAwAEAAAAAQAAAMAAAAAA/9sAQwABAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/9sAQwEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEB/8AAEQgAwAEAAwERAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkK C//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHw JDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3 eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY 2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1Lw FWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2 d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW 19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A/v4oAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA/LXx3+3Z+ 0sn7SH7TvwQ+AX7E2m/H7QP2UdM+Ed94/wBctv2ltD+HPxJ8VXfxa+H83xD07SPhr8NfFPwr n8Ia5qFjpttPpyDxL8Z/B0GoaobeITWcE7TxAHsuj/8ABSP9i+5/Zw+C37VPi746eDPhL8J/ j3oJ1r4fz/F3VrDwJ4luLqwtLi48XeGr/wAN6jdvfw+Jfh1NY6rYfEWysxf2vhG60bVJtTv0 061N+4B2vxP/AG7v2Mfgvo/hfxB8U/2ovgb4H0Txz4N034h+BtT1z4j+GYbTxv4F1dh/Zni7 wZLHqEo8WeH72EtfQap4f/tG0bSobrVzKNLtLq8hAOOu/wBsLS739rT9nP4L+Db3wF4s+DHx 4/Y//aI/altfjBpHiKLVLCbT/hF47/Zg8O+Fbvw3renX0vhjUvBnibw98eNY1671sTXEbx6T o9zYXiWct2ZwDW8H/wDBRH9hP4g6F8T/ABP4H/a3+APizw98F/CNx8QfilrGgfEzwxqdh4L+ Hto88Vx8QdXuLW/kT/hAY5ba5hPjW2Nx4Yaa3mhXVWlidVAOk/aS/am8D/Ajwb4kuLPxd8Gr n4n2Pwy1b4t+GfAvxS+Ltt8J9B1vwD4f8V+CvCHiHxlrHjOHwz46uvDvg/StX8f+GNNfxGnh PWLObW9c0TR1CPqX2m3AK3xH/bu/Yw+EHxCX4TfFT9qP4GfD34mHxLofhCTwJ4w+JHhjQPFF t4i8TaZ4Y1jQLC+0jUdQgu9PXVtP8a+DpbK+vo7fT5pPFXh21F39r1nT4LgAg+Of7ev7GH7M 3iy18CfH79pv4N/CbxneWej6gnhjxn420nStagsvEd3e2Phq51DT3na40uLxNfaZqdn4ZbU0 tP8AhIrrTNSt9F+3S2F4kIBJ+1r+1fo/7L/w88CeItN8D698Y/iN8avih4O+CHwA+E3hDU9G 0fU/in8V/HtjrOs6Ho58T6/PBoPhTwvpXhbw14p8deNfGWqNcWvhrwP4V8Qa1Dp+sXtrZ6Pf gHkvwZ/bO+LV9+0lo/7J/wC1l+zZpf7OfxY+IPwu8XfGD4Ka34C+NkHx++EvxW8MfDjXPC2h /E3w7ZeM7z4afBrxN4f+JPgFvHngjVtY8K6r8Pn0q/0HXm1TQPFWrR6ZfRxgGJ+y5/wUe8M/ tN/tb/tM/svWfwy1jwbp/wAGo9V1H4PfFW+8S2msaJ+0p4d+G/xN8S/Ab9oTXfCujW2j2b+G ofgj8fPDMvw21iGfWfEP9tpq+geIYJtNg1NNPjAPsHTv2i/gRq3hz4deL9M+LfgK+8L/ABd8 dX3wx+GGv23iPT5dK8efELTf+Ew+3+DfC96sxh1fxDaf8IB428/TLVpLlD4W1sFM2E+0A/Lj xB/wW1/Zl8X/AAS8Y/Fv9nrxn4F8VN8Lv20/gZ+zF8TLPxv4l0bTrDRPh/8AEX9sDwP+zV4k +OcV7oniC7t7TwHe+Hdf17x58PfEGuXmmw3dnYWV34j0uwtxeWdAH6ffAj9pf9n39qHwzq/j L9nb4y/Dr40+F9A1+48La7rXw58VaV4ostF8RW9pZ6i+j6q+mXE76ffS6ZqOnataRXaRG/0f UdO1ayNxp1/aXUwB+fngT/gqH4D8fftzftbfAJfix+zD4J+CP7FXhu3/AOFu694y8d39j8S9 R16x8NWmu/EbxbaXt1d6V4B8H/Df4O65rOifD/xvJ4hfUL5vE41uRtT0ePToLK+APsjwP+3L +x38S/hz49+LvgL9pb4NeKvht8K7qxs/ib4v0nx1oc+lfD641UWz6QnjRjdJP4aXWYry1udG l1iGzh1ezuIb3TZLq1kWYgHffDP9pL4BfGb4Zax8afhR8XvAPxC+EmgTeJ4NX+I/hPxHp+s+ DbI+DUkm8TTPr9pLJp0lnpNtE17Nfwzy2MuntFqFtcT2U8FxIAcD8Lv26P2M/jb4g8XeFfhH +1H8CfiL4h8BeD3+IXjLSvCfxN8J6xc+HPAluYE1Dxhqn2XU3jg8N6LcXNtZeItZLmw8N6jc Q6br0+nX8qWzAHAt/wAFK/2Hr/4SfHH4z+DP2kfhV8R/CH7PPgsePPiYPA3jTw/q+p6T4fvo r7/hF72O1l1Gzjk0/wAd3+n3Gj+B9feeLw14m1VWt9N1qZYbiSEA8W+GP/BXj9j/AONk/wAJ dX+GPxt+Ad14M8UfBHx58evjJB4v+NWkeG/iv8EvBfg74eaN8QZpbn4a6bofibT/ABY2gWV5 rMHxUuU8ceH7L4d22hyapDceKYLgxW4B9+ar8dfgxod/4P03Wfin4C0q8+IHgXxd8UPBUeoe KNItE8TfDfwBYeHdV8b+PtJuJ7tLe68HeFNN8XeF7/X/ABIs39kaZaeINInu7uOO/t2kAOS+ A37WH7M/7UUXiib9nb46/C/4zjwVcaVb+LY/h54w0fxJdeHf+EgtZr/w5d6tZ2FzLd2el+Jr C2ub/wAMaxLCNK8SWNtcXmiXl/bQSyoAYvin9tP9krwR8adK/Z08X/tGfB/w58cta1fw54es Phhq/jnQrPxYfEvjK0gv/Bvhe70+W7H9m+KvGVjd2d54Q8M6nJaa94ptb6wuNA0/UYr60eYA x9Z/b0/Yr8PfFbTvgZrv7U3wK0f4w6r4zHw6s/htqXxJ8MWfi8+PJbmOxsvCNzo0+oJd2HiD V9QlGmaBpl+ltdeItVSfTNDj1C/tri3iADxn+3p+xX8O/iXH8GvHn7U3wK8IfFV/GunfDp/h /wCIviR4Z0rxTaeN9Z0zwrrGi+G9S0m81CK50vUdbsfHHg9tFXUktY9YuvEuj6dpsl1qN9Da sAdtaftVfs3ah8cLv9muw+N3w2vfj1YCZb74U2ninTLnxlZ3lv4di8Yz6RdaXDO72/iGHwdP D4wl8NzMmvx+EpY/Ez6cNDcX5APf6ACgAoAKACgAoA/GCa2/bQ/Z5/bk/b8+JXwr/Ye8bftA +GP2mbH9mO9+EfxDsfjd+zd8OfhdYaz8K/g3c+CPENh8TD4y+KsHxo8PWNt4juojJfeE/gn4 6kuNLhurrTbW+uBbWtwAfHFp/wAE3f2o/wBlK/8A2HfFvhu4/aB+NkXwn/Za+P8A8G/jjF+x L44/Z7+HnxI8P/Gf4/fHvw3+0j4x8aeBNN/a11Xwp4N8RfBvxP4xk8TeFdXsbfxV4b+IFjY+ Gfhpqr6PqtiuuWOlAGf4H8G+JP2Kv24P2M/BfwN/Yk+MXxmh+G//AASo+L3h6D4L6h8Vf2bb j9oL4T6d4p/al8B6qTN4v8YfEDwf8D9eW01u/tfCvi618FfFKz07RfDmo+b4Tj8XaToQ0y5A MyP/AIJR/tdXv7OfwW+AUMHhzwX4g/4dE/8ABT79mbxP4t0jxfpM3gr4SfHT9sH4w/s8fEr4 X/B62e3uI/FWreDNA0fRPGfgZ/FvhbwxfaJY+HPA00vm2U+qeG7DUwD7N8L/ALP3xe/a/wD2 hfgB4q+O37FOq/sjfBP4C/saftJ/szfE3wd428d/Ajxe/wAaD+0npPwf8H3/AMJvhvZ/Af4k /EeL/hQHgjQPhxrmsReIPiFN4F17U9T1DwlaaR8OdOMHiC6sgD8z/wBn/wDZV/aj/ak/YJ/4 KAXOtWdj8YfjX4N8HaB/wSg/Zc1mz8TaBb2vxQ+DX7AXxf1Tw/4n+Llp4n8QahoXhq11f41/ E+TxZceM7m+1OH7Xe/CnQrea8ea0t7cAH6B/tRfsM/G/4leBv+C/UPhb4P6Vrvi/9tn4T+BP Cv7Nd2+ufDyy1T4oaj4M/Yz8L/D7SNLfVtU8QWbeE4PD3xgtdXtNHPj+88MWFjqjXHiOwlTT bv8AteYA/N79rrx/faB+1t/wUy8afEebxj4i/Y6+FXxh/YU8WftVeBPhR4+/Zz0X4k+KPEX7 O3wa/Z1+M3hyxtfCnx0m0X4q3+rL4nj8Nmdvgxr9vpnxV0CHSPBfwxurD4r2XjTUNQAP3y/4 KEfBP4y/EzTf2Ufjn+zv4V0z4h/Ff9jz9p7w7+0Tpfwk1/xFZ+BX+LngzUfhZ8U/gv8AEj4f 6N4l8RLF4f8AC/jq58E/F3VNf8F6h4ufTtBXxP4dsdH13U9E0/VLzVLIA+VfiNpH7dXx9+NV t+2Zo37HPij4K6z+x1+yb+1V4b/ZW+BfxX+Kf7Peq/Fz4+ftR/tBaT4DsNMuPEFx8M/ix8Qv g34A+EvhCy+GVppMF94i+LEXiDxFqHjG91O70HS9P8P2i6mAeRfDH/gmP+1x+yL4k/4JnfEb wF8eNY/aYvP2VvFF98Hfip8Ob3wX8HfhtGfgL+1BpaWH7TfjpPHaSeGfE3jy+8MfFew8CfHu 50zxFrGr+IfFU/gzU5tN03V/FeowWF+Acz8I/wBmj9uDQNN/YC/Zg1r9k7WNJ8D/ALF3/BRv 4ofHrx9+0hefGH4ITeA/Hnwl12+/a4n8A+I/hZ4L0rx3qfxT1Ge80r45+HH8daT478H/AA91 nwrq9qdO8PaX46tbi+1PQwDa8S/si/tQeK/hF+0j+y5rn7L+s6zoerf8FiPhb+2RoPj/AFbx l8CdS+Enxe/Zx8Z/8FE/hf8AtH+O4bPRb/4lt44ttd+Hnww0/wAYL8QPBnjv4e6DFrY0hNO8 DXHjm91y00wgH6a/AX4J/ETwN+3h/wAFAPjJrnhePSPhn8dfDv7Hw+H3iKLVNBuB4t8QfDDw D8RvC/xAnn0fT9SuNc0270VL3wfpT3niHTNNGqWkdimkzahaadKbUA+B/wBpr9iH9pf4j6x/ wUw8Q+D/AIeaR4jh+J37Wf8AwTc/aP8AhB4G8ReMfCel+Hv2lfB/7IWgfs0eI/ih8JtYupdR vl8IQ+M9T+E/ifwFYSeP7DRNIvNaOm3uoOPCF1PrIAPMP2qv2S/2rf22NG/4KI/GS2/ZW8S/ A/Ufjx+xX8Bv2S/hx+z98UPHnwAv/iZ8YNe+HXxs8e/FPxX8QfiHe/DL4r/ED4N+HNC0jR/H Y8EeALTVvilq2vapp8Piy71e28PWd1oOmXgB+6fx18D3/iP9nT4x/DbwHolodT174K/ELwP4 M8OWB07R7E3+qeBtX0Hw7olkbiSw0jSrQ3E9nY25mms9OsYdnmSW9tEzIAfkHafsdftT/Dvw n/wTAv8A4K/CTwHonxJ/ZV/4Jh/tT/AzxLZ+IdU8E2/gPwh+0F44+A/7NOn/AAx8D+MLLQ9a M/inwf4g+MHw21xvE994Lh8QaGkWkXurXmowrqWmXl+AeX/s9fstft2/Ez43/GT4ofH/AMH/ ALQOg3PxO/4Je+NP2XNQ8V/tQ+PP2NNQ1Rvj/r/jCz1u+0zwn4R/Y4mudA0D4PxXGsa7eeEN U1hL3Wpre31ptR0/QHudLTxEAesfAj9nL9ob4it/wSWj+NX7LXij4X+Hf2V/2bf2iP2bf2k/ C/xF8bfA3xRayS65+zp8GfhRpuraMvw0+KfjuLxX8PviVrnhrxZp2gSQi38SxaTYtf8AjLwt 4Tt9R077WAfIng7/AIJZfttfEL9lr9tf4L/F6PS/D3jj4b/sg3v/AATS/wCCf/iPV/HXh/V7 X4n/ALOHgT4k+KviFp/xJ8Y32hTeJ7rwU37RXg2x/Z++EHj/AEzxRp//AAkGkr8Hb/V9W8NX 1jqFodQAP0r/AGEPgb4osvjx42/aE+KXwZ/bj+HnxUm+BvhP4H3HiX9rr4ufsfePNJ1PwvpP jLVfGieDPh7pn7KXjPxMb7SvCfiHUNV1DT/FnjrTPDUklp4jurbQdNjN/rFtaAHx9+3v8DP+ CkX7Q/xT+Mfw10v4f/GTxB8IB+1B+xZ8SvgHP8OvG/7Gngz9maT4O/CX4hfs7fEr4ma38aP+ E4uoP2t/EPx/0jxp4F+IM2k6XoR074fP4f0r4d/8I/qkU9jrdj4iAPnWf4a/tA/tGaR/wVo/ ZD+Ef7KN3rmm/tBf8FS53u/2u4PHnwb0bwN8JovBT/sveKPE/iH4keHNf8VaF8aLvxd8NNE8 NweIPhLB8O/BPxItfEOv6lZ2lzqvghdL1G5YAsfFP4d/tAftA+J/+C937I3wW/ZKl+Isn7WP 7U/w/wDhMn7Tq+O/g74f8IfBnVLr9iL9jWC71v4waJ4u8WeGfivc6N8INJ1n/hafwtk+FXh3 4qahrnjW91vRP7G8C3aQ6/roB+jnw7+E37TXw5/4KG3Ot/A74V/H34V/s5fEn4nfEbxn+2Pc fFfx5+zd40/Zr+Ltwvwgm8MfD/4z/s76PoHj7xL+0v4B+OXjDxv4c+GkXjzQNU8LeAvhdc+F rHxxf69oM/ir/hF9b14A/ZWgAoAKACgAoAKACgAoAwW8LeGH8TxeNm8OaC3jODQbjwtB4ubS NPPieHwxd6hbatdeHItfNudVj0G51Wzs9TuNIS7GnzahaW17JbtcwRSqAb1ABQBz/hbwn4V8 D6HZ+GPBXhnw/wCD/DWnyX0th4e8LaNp3h/Q7GXU9QutW1KSz0nSba0sLaTUNUvr3Ur54bdG u9QvLq8nMlxcSyOAdBQB5H4i/Z/+A/jDx/ovxX8W/BP4R+KPil4b+yDw78SvEXw38G634/0E afIZrD+xfGOp6NdeItL+xSky2n2HUYPs0hLw7G5oA9coAKACgAoAKACgAoAKACgAoAKACgAo AKACgDB0Pwt4Y8MSa5L4b8OaD4el8T69d+KfEsmh6Rp+kyeIfE+oW9nZ3/iPXHsLe3bVtevb TTtPtbvV783GoXNvY2cE1w8VtAqABo/hbwx4evvEmp6B4c0HQ9S8Za1H4k8X6ho+kafpl94q 8RQ6LpHhuLXvEl3ZW8M+ua1F4d8P6DoEeqapJdXyaLomkaWs4sdNs4IQDeoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD//2VBLAwQUAAYACAAAACEAUGQT 1RgCAAC4BAAAEQAAAHBwdC92aWV3UHJvcHMueG1slFRNi9swEL0X+h+EjoWs7bDrpibOUigt hYUGkvauyLKjVl+MZG+yv74j23E23RzSm+dDb957M3j5eNCKdAK8tKak2V1KiTDcVtI0Jf25 /TpbUOIDMxVT1oiSHoWnj6v375au6KR4XgNBAOMLVtJ9CK5IEs/3QjN/Z50wWKstaBYwhCap gD0jsFbJPE3zRDNp6Pgebnlv61py8cXyVgsTBhAQigUk7/fS+ROa5rfAaQZ/WjfjVjuE2Ekl w7EHnWC6krZgilHSTEsO1ts6xDeFZrzotKJE8+J7YyywnUKHdNdn1iC8gE58DgHkrg3Cx1Lx 4YTtbmHoIogJvcBL1xTz4RcuoKReVdt9q3eGSRUzdIW7QTaa9eEaYow4wYKonkQdiH/BTT/k 85Qmr2tb6/rSp/s870vJWxyvZCXilAGWb1Q1RMQb5rb2G8iqpHhEQ/hj91vwgMqznhUfezsG G86iWUPex2C1ZIU/kHiF6QMlCJOlPQ1MH6+kkd34zhUWZCMNOZR0trjH6Uf8yAZ92DaOjVqb Fvk/+TB9E3yKDuMyLLxQ4iySnWeD/rF9TC4WJ1POIBF8smC1jJQuDTIWF78Vh35Xo2dn+97o RurXdF+k45DBr9e6B9EnhpNibL5CwVsIAs48pvYJ+rSKPL/G6DL7v4T+nd7gzWwc4/hnIBxX +HGRztFsVMRxj1OEt4qTuuH2/gIAAP//AwBQSwMEFAAGAAgAAAAhAHsXeNH5AAAAwgEAABEA AABwcHQvcHJlc1Byb3BzLnhtbIyQwU7DMBBE70j8Q+QjUuqUA0JW0woJVeLWA3yA42wSq17b 2nUC/Xuc0CK45bg7mrezszt8oSsmILbB12K7qUQB3oTW+r4WH+/H8lkUnLRvtQseanEBFof9 /d0uqkjA4JNO2XqiIoM8K12LIaWopGQzAGrehAg+a10g1CmP1MuW9Gc+gE4+VtWTRG29uPpp jT90nTXwGsyIOcAPhMAtSXiwkW80NGtwqOk8xtIEjBnRWGfTZYH+YqZajOTV9aUSraHAoUuz R6E2akInCjTqrfeBdONyUzgtm9PcEk3wkhLZZkzAs6Qebuy4JuHfqv+1JvffAAAA//8DAFBL AwQUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAHBwdC90YWJsZVN0eWxlcy54bWwMzEkOgjAY QOG9iXdo/n0tQ1EkFMIgK3fqASqUIelAaKMS491l+fKSL80/SqKXWOxkNAP/4AESujXdpAcG j3uDY0DWcd1xabRgsAoLebbfpTxxT3lzqxRX69CmaJtwBqNzc0KIbUehuD2YWejt9WZR3G25 DKRb+HvTlSSB5x2J4pMG1ImewTeqgiCitMCny+WIaUgDXHo0xnFU1tW5qf0qLH5Asj8AAAD/ /wMAUEsDBBQABgAIAAAAIQDid2e/bAEAALgCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQB KKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMUl1PgzAUfTfx PzR9hwKbiyHAEjV7krjEGY1vtb3bmtGWtN3Y/r0FNmTRBx/b83HPPW02P8oKHcBYoVWO4zDC CBTTXKhNjt9Wi+AeI+uo4rTSCnJ8Aovnxe1NxuqUaQNLo2swToBF3knZlNU53jpXp4RYtgVJ begZyoNrbSR1/mg2pKZsRzdAkiiaEQmOcuooaQ2DenDEZ0vOBst6b6rOgDMCFUhQzpI4jMkP 14GR9k9Bh4yYUrhT7Xc6xx17c9aDA/toxUBsmiZsJl0Mnz8mH+Xza7dqIFTbFQNcZJylTrgK ilJ/iQrQC927LeLARFs1WhsqodFml5GB2WqYAeq0KZZ0X6GScguqY1zu294ral3pn2gtgD+c rqm/4VZh4NCNLZIoI+OzH9m10s8Fjvyead/KBXmfPD6tFthL4ySIpkESreIkvUvS6f1nG+1K 3+7dX8hzwP87ztIoGjleDIou8fVfK74BAAD//wMAUEsDBBQABgAIAAAAIQAYBF+Y+AMAAMsk AAAoAAAAcHB0L3ByaW50ZXJTZXR0aW5ncy9wcmludGVyU2V0dGluZ3MxLmJpbuRZX2+bMBDP 9pZoH2CPLO/BTf8lm2iqLmm1SGmLmmTSnioX3IyOYATOuuyL7OvuDBgcIDTbQwv0oRJ17PPd /e6v722j0XgDf8r7RkM7/bW0lZ/E8y3qnLS76l5bIY5BTctZnLTns4tOv306aGkfRtfD2Tf9 XHFty2eKPv88GQ+VdgehM9e1CUKj2UjRJ+PpTAEaCJ1ftZX2d8bcTwg9Pj6qmO9SDbrkG32k e9QlHltPgFgHDqgmM9twTUh9gx1YNS2DDVpN7QdZD4BERMz1LIepOl6QC+otMXxefqGe9Zs6 DNs3xNcQ3w/HouP555ll/CBMNTyCGfXEmabmMyC/kK57oHfhXg1Fv7WahSQtRpZnnofXCVHM /wWW4KBgaguNp8XiRIBpe9Db11DwwekWcuQzzMiFjRcxR7AflEgWxBvsaUh8BgwiwaGGBNua WHsaiWvPIoADA6sSl8Ui556uAg45QnGNC7V1NzVYFiimBrbBlOsDQ0qg2BFA/6Xzg68Q5SwA oFbxKEeoGIRSRiPBcMpyqh+RtggWo1ESl/BXd7Mwz7oY8v6t5dzT2zDi54cl/VLXRzrfO6Qm ucJLIvZJmfNf8siuCb0waGczelMTuZGr3AzrFPgMyRRIwbdEZcSEMEag8kiqCnE+XeuEGlPz 0niShVJ5vBknbbgxzuTSaqBF/XJm0QUONF5dbW+RQdK1gzt2CdSdBnaj2jszH1Y+IyZfvCEG q6Ll/5+AHCjJn+A/UVqljbr4p7AsPjiU6wE4ESwf9Y43liWfeH6321FNEAZrbghpCbOWEIDX 6fY3wIsw3bLc6+VbwMfN5ZJZAKhiDOkRutlKR+OsaRcJVoUQnfA/d3AtY/ROEmZd89UF6Xw9 wWp9ovRuImZt4dWFadc16xuqtwknhev5VClDA5NON1GrdKaPoUXmb9tJFR31WXt76j6UlUnX VdROsrUrdaDRmfSdQb7muXsW9LoS7bgHK7ojy6voENOsFlGRORXns4yKN/M0p4JRDQUv8YMW nxX8eVeDOcGIGqslPEmHEoPLTl1K7XByIGwjbuCLFFy2ScEugkn+ygcx8CDJH+aRa95LRso3 5U1YIlfKe3XY1p8JMwKK8ZNDvJZ7ic6HOVNozeGl2gd0htSm3nTtGDApurdsMh5VGqTdxeMo iIKqe9RPN765ynshhFyr6kO2jNHJIm0gUZ7RTpbnNTiLDZO9mnmIm5aLA8K8FUHBBLVEwerC 8nzGn+tqhUBGqmo4xATXEIu0UDIU+93D3mH/4PiwV9ogFTxlY6dmDpKRiqMiv18niTyFTJLi t4MXF06c6ovVZVFp8Yy9iZzfwmI9qVFFDRm3J38BAAD//wMAUEsDBBQABgAIAAAAIQBHJA1n iQIAAPYFAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxU3W/aMBB/n7T/wcrT9tCGFMYYMqkqUFVpYyCRds+e fSHWHNuyXVr21+8SlwArRdrydL7f5T5+90Gvn2tFNuC8NHqSZJe9hIDmRki9niT3xe3FKCE+ MC2YMhomyRZ8cp2/f0eXzlhwQYIn6EL7SVKFYMdp6nkFNfOXCGtESuNqFvDp1qkpS8lhZvhj DTqkV73eMIXnAFqAuLCdwyR6HG/C/zoVhjf5+YdiazHhnBZQW8UC5DTdi4UJTBWyhjwbfUKg e9IfxgmfD/tDmkaR3lirJGcBacrnkjvjTRnInHGpg/EVWZoncEuDL5oe2iJP4LHY9s/blot8 oS88dwCarCrzRD4Mxv2PND1hSJfMsbVjtvJ5djVAm/2brpQU0Ohp+iLS7yagpkfTKNA7KQTo FxTVR286n0+VtK39TqQrzhRMkbq8ZMoDuu4U9A5YMxZLJp3P6SaMN8CDccTL3zgYg4T8ZB4a wifJhjnJdEDiG7P4aGVlfXD5DLxca7LrBE3RKiKtePjDoSwHedYaoHDWMPpq6yaFDAr8v4RA QjGfVzEaZawYgx9zEWMsSmxPOEFN1j/kpk0uMhPzXLRbQQpcGyR8T0UnzcAqs0XqyeLmMVQE V4poHKgNEGbtUW3dPzhNtWwa2GmaVsSA0wrHiAdw0gfJT///FbZkWhlc19N4JBe3pvO69x8x 3J03sc9nsNEZ7MsZLMMBfzNgFgcn1r/PdGpqi9PpjSamJEKWJThcVsKQZk1qI0Adld8E6Gbg r663vvQWh6OTvkn9y9/bwsya0/OyUcdKusJmgMCbuMP3CnqHy+RU4wRbptcgdjavgeZAPcQz jifhsodfe4h2uua+7A52/gcAAP//AwBQSwECLQAUAAYACAAAACEAHnYF11gCAADpEgAAEwAA AAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCj7IIm DQEAAOICAAALAAAAAAAAAAAAAAAAAJEEAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBL 9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAM8HAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54 bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAMwIAABw cHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAA ADcBAAAgAAAAAAAAAAAAAAAAAMkJAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVs c1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAMYKAABwcHQvc2xp ZGVzL19yZWxzL3NsaWRlNi54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAg AAAAAAAAAAAAAAAAAMMLAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc1BLAQIt ABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAMAMAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlMy54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAA AAAAAAAAAL0NAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNy54bWwucmVsc1BLAQItABQABgAI AAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAALoOAABwcHQvc2xpZGVzL19yZWxzL3Ns aWRlOC54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAhAAAAAAAAAAAAAAAA ALcPAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTIueG1sLnJlbHNQSwECLQAUAAYACAAAACEA S/U97L8AAAA3AQAAIQAAAAAAAAAAAAAAAAC1EAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEx LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACEAAAAAAAAAAAAAAAAAsxEA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3s vwAAADcBAAAgAAAAAAAAAAAAAAAAALESAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlOS54bWwu cmVsc1BLAQItABQABgAIAAAAIQDhYoamhQEAADUKAAAfAAAAAAAAAAAAAAAAAK4TAABwcHQv X3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGJtky7sAgAAsQ4A ABQAAAAAAAAAAAAAAAAAeBYAAHBwdC9wcmVzZW50YXRpb24ueG1sUEsBAi0AFAAGAAgAAAAh AOienRYzAgAA+QQAABUAAAAAAAAAAAAAAAAAlhkAAHBwdC9zbGlkZXMvc2xpZGUxLnhtbFBL AQItABQABgAIAAAAIQCbtX0VRAUAAGUaAAAVAAAAAAAAAAAAAAAAAPwbAABwcHQvc2xpZGVz L3NsaWRlOC54bWxQSwECLQAUAAYACAAAACEAzPJnApUFAAArGwAAFQAAAAAAAAAAAAAAAABz IQAAcHB0L3NsaWRlcy9zbGlkZTkueG1sUEsBAi0AFAAGAAgAAAAhALZ2NVF+BQAAyRoAABYA AAAAAAAAAAAAAAAAOycAAHBwdC9zbGlkZXMvc2xpZGUxMC54bWxQSwECLQAUAAYACAAAACEA shXO0ekGAADaIAAAFgAAAAAAAAAAAAAAAADtLAAAcHB0L3NsaWRlcy9zbGlkZTEyLnhtbFBL AQItABQABgAIAAAAIQB8rlBcyAUAAGUbAAAVAAAAAAAAAAAAAAAAAAo0AABwcHQvc2xpZGVz L3NsaWRlNy54bWxQSwECLQAUAAYACAAAACEAu8RssT0FAABnGgAAFgAAAAAAAAAAAAAAAAAF OgAAcHB0L3NsaWRlcy9zbGlkZTExLnhtbFBLAQItABQABgAIAAAAIQA/6IWpDgUAAHcZAAAV AAAAAAAAAAAAAAAAAHY/AABwcHQvc2xpZGVzL3NsaWRlNS54bWxQSwECLQAUAAYACAAAACEA Dz9iDIYDAABWCAAAFQAAAAAAAAAAAAAAAAC3RAAAcHB0L3NsaWRlcy9zbGlkZTIueG1sUEsB Ai0AFAAGAAgAAAAhACpc8vSjBQAA7hsAABUAAAAAAAAAAAAAAAAAcEgAAHBwdC9zbGlkZXMv c2xpZGU2LnhtbFBLAQItABQABgAIAAAAIQDUqMVV3wMAAIwJAAAVAAAAAAAAAAAAAAAAAEZO AABwcHQvc2xpZGVzL3NsaWRlNC54bWxQSwECLQAUAAYACAAAACEAFF+KzXsEAAC3DQAAFQAA AAAAAAAAAAAAAABYUgAAcHB0L3NsaWRlcy9zbGlkZTMueG1sUEsBAi0AFAAGAAgAAAAhANXR kvG+AAAANwEAACwAAAAAAAAAAAAAAAAABlcAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAA AAAAAAAADlgAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAFlkAAHBwdC9zbGlk ZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXR kvG+AAAANwEAACwAAAAAAAAAAAAAAAAAHloAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQ0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAA AAAAAAAAJlsAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAALlwAAHBwdC9zbGlk ZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ5LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXR kvG+AAAANwEAAC0AAAAAAAAAAAAAAAAANl0AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAAAAA AAAAAAAAAD9eAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJl bHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAABIXwAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh ANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAUWAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMv c2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAA AAAAAAAAAAAAWWEAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAYWIAAHBwdC9z bGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh ANoks5/WBwAAaC4AACEAAAAAAAAAAAAAAAAAaWMAAHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVN YXN0ZXIxLnhtbFBLAQItABQABgAIAAAAIQCeTIu89QIAAFYHAAAhAAAAAAAAAAAAAAAAAH5r AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWxQSwECLQAUAAYACAAAACEAJE5z rGgDAAD3CAAAIQAAAAAAAAAAAAAAAACybgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91 dDYueG1sUEsBAi0AFAAGAAgAAAAhADoTQU26BQAAKRsAACEAAAAAAAAAAAAAAAAAWXIAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQCdmOqBZwQA AHQRAAAhAAAAAAAAAAAAAAAAAFJ4AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54 bWxQSwECLQAUAAYACAAAACEAeAMAOdMEAAASEQAAIQAAAAAAAAAAAAAAAAD4fAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1sUEsBAi0AFAAGAAgAAAAhAJZ+OZSbAwAA/woA ACEAAAAAAAAAAAAAAAAACoIAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbFBL AQItABQABgAIAAAAIQBOhpyYhQQAAIgQAAAhAAAAAAAAAAAAAAAAAOSFAABwcHQvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwECLQAUAAYACAAAACEAJ3ACaQgFAADqEQAAIQAA AAAAAAAAAAAAAACoigAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDkueG1sUEsBAi0A FAAGAAgAAAAhAFBRu2ArBQAAHhIAACEAAAAAAAAAAAAAAAAA748AAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQ4LnhtbFBLAQItABQABgAIAAAAIQCPj32K+AMAABYMAAAiAAAAAAAA AAAAAAAAAFmVAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1sUEsBAi0AFAAG AAgAAAAhAPtfKwknAQAAYwgAACwAAAAAAAAAAAAAAAAAkZkAAHBwdC9zbGlkZU1hc3RlcnMv X3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEyAFDq0AwAANgsA ACIAAAAAAAAAAAAAAAAAApsAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWxQ SwECLQAUAAYACAAAACEAKQtbINMDAACLCgAAIgAAAAAAAAAAAAAAAAD2ngAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDEyLnhtbFBLAQItABQABgAIAAAAIQDEE7BmAQcAAJMdAAAU AAAAAAAAAAAAAAAAAAmjAABwcHQvdGhlbWUvdGhlbWUxLnhtbFBLAQItAAoAAAAAAAAAIQCy SkAu1iAAANYgAAAXAAAAAAAAAAAAAAAAADyqAABkb2NQcm9wcy90aHVtYm5haWwuanBlZ1BL AQItABQABgAIAAAAIQBQZBPVGAIAALgEAAARAAAAAAAAAAAAAAAAAEfLAABwcHQvdmlld1By b3BzLnhtbFBLAQItABQABgAIAAAAIQB7F3jR+QAAAMIBAAARAAAAAAAAAAAAAAAAAI7NAABw cHQvcHJlc1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQDY/Y2PrAAAALYAAAATAAAAAAAAAAAA AAAAALbOAABwcHQvdGFibGVTdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAOJ3Z79sAQAAuAIA ABEAAAAAAAAAAAAAAAAAk88AAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhABgE X5j4AwAAyyQAACgAAAAAAAAAAAAAAAAANtIAAHBwdC9wcmludGVyU2V0dGluZ3MvcHJpbnRl clNldHRpbmdzMS5iaW5QSwECLQAUAAYACAAAACEARyQNZ4kCAAD2BQAAEAAAAAAAAAAAAAAA AAB01gAAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAAPgA+AI8SAAAz2gAAAAA= --------------020900090709080206050101-- From tbray@textuality.com Thu Apr 19 20:41:07 2012 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 485AC11E80E9 for ; Thu, 19 Apr 2012 20:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EElsWkQS4Qd for ; Thu, 19 Apr 2012 20:41:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F89F11E8091 for ; Thu, 19 Apr 2012 20:41:06 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so8727834obb.31 for ; Thu, 19 Apr 2012 20:41:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=72b05hnVj00AJvoQL2ukZ5GlCptUCzSUggrGXybI3RU=; b=kCAzLgwMuXgg8u4w0CWFsWEasN9WQfn5AJkA1Q0nu9YdC1+iVVN2LyMQpV2OcU3eZT Vu2XAOysZW+ohkClS1PrtbCLtqoVbM8oj+JpUjVfFMyjTyyMl4D4whV3Dkb43OZrTqkZ O5EJKbjLooLdiG61o7BaYr+/veT8Vd7ozAIKplGGyVWJD500EHxZ2BGBt4mkwv36Ls4R lkiLuzysbMazltTrHgiZ5awJCxS6Pp0qnLFQilOitE2MXLWtMIEZa93mK0KrhMaYnhXI KDTq9zeElPilovxv8q8X2IlsCYUc/fXhWk8W2SjjxCBKemYxA57k7ufd7e1+zsU3LejG LYZg== MIME-Version: 1.0 Received: by 10.60.11.166 with SMTP id r6mr6437960oeb.2.1334893266007; Thu, 19 Apr 2012 20:41:06 -0700 (PDT) Received: by 10.182.29.6 with HTTP; Thu, 19 Apr 2012 20:41:05 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> Date: Thu, 19 Apr 2012 20:41:05 -0700 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlCISGheV47+nwTx5j/6tCBYSd6ZC6UMAyhCpxOWWi6N7dwWBBUanYNbWPZbC8asjGSCWnw X-Mailman-Approved-At: Fri, 20 Apr 2012 06:57:38 -0700 Cc: oauth@ietf.org, Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 03:41:07 -0000 No. Supporting two different on-the-wire data formats is actively harmful. Here are two pieces which explain why: - mnot, this month: http://www.mnot.net/blog/2012/04/13/json_or_xml_just_de= cide - Me, back in 2009 Pick one. -T On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones wrot= e: > Mike, > >> There are two criteria that I would consider to be essential requirement= s >> for any resulting general-purpose discovery specification: >> >> 1. =A0Being able to always discover per-user information with a single G= ET >> (minimizing user interface latency for mobile devices, etc.) > > WF can do that. =A0See: > $ curl -v https://packetizer.com/.well-known/\ > =A0 =A0 =A0 =A0 =A0host-meta.json?resource=3Dacct:paulej@packetizer.com > >> 2. =A0JSON should be required and it should be the only format required >> (simplicity and ease of deployment/adoption) > > See the above example. =A0However, I also support XML with my server. =A0= It took > me less than 10 minutes to code up both XML and JSON representations. =A0= Once > the requested format is determined, the requested URI is determined, data= is > pulled from the database, spitting out the desired format is trivial. > > Note, and very important note: supporting both XML and JSON would only be= a > server-side requirement. =A0The client is at liberty to use the format it > prefers. =A0I would agree that forcing a client to support both would be > unacceptable, but the server? =A0Nothing to it. > >> SWD already meets those requirements. =A0If the resulting spec meets tho= se >> requirements, it doesn't matter a lot whether we call it WebFinger or >> Simple Web Discovery, but I believe that the requirements discussion is >> probably the most productive one to be having at this point - not the >> starting point document. > > I believe WebFinger meets those requirements. =A0We could debate whether = XML > should be supported, but I'll note (again) that it is there in RFC 6415. > That document isn't all that old and, frankly, it concerns me that we wou= ld > have a strong preference for format A one week and then Format B the next= . > We are where we are and I can see reason for asking for JSON, but no good > reason to say we should not allow XML (on the server side). > > Paul > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From tbray@textuality.com Thu Apr 19 22:32:43 2012 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 201DA21F872D for ; Thu, 19 Apr 2012 22:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vir3yDIQtlGF for ; Thu, 19 Apr 2012 22:32:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D29D721F872A for ; Thu, 19 Apr 2012 22:32:41 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so8838567obb.31 for ; Thu, 19 Apr 2012 22:32:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=xrDORFyJlovEq4/YxpSX574sfol/ig0X/LVK51ConrU=; b=Ybx2N8fUGti3xeCJ6W0J+KTcQb2GNX0q0BuXnmx2PWUMyGjBTnPCQ+1vQgJVTEblUe SCJPP2NV7+G1srfMS9SHXGkZHyA4tz23+Pm2HwTHHXAhOuHXw5hd7fzXzhDjEvAMw546 eXxJW9tUizqUl2ikw01pt53vUgSkAmkCJY4iUJxPsjWYMefqthZHKDnoW6ttXaYloi5l y14SnyJyuUcq0GGyd2hVARwBVBQJ6mZvG0K6UDCGlVFIcJ2fP2NRRZKJUK0vR28uJ6H0 myxOCEVvpbVGfhIj46WzfsSgn7j8tiooX+dMm0Mj4ufFmZVMip5d1h+aCNrtflnudLep KB8Q== MIME-Version: 1.0 Received: by 10.182.225.2 with SMTP id rg2mr6859692obc.2.1334899961439; Thu, 19 Apr 2012 22:32:41 -0700 (PDT) Received: by 10.182.29.6 with HTTP; Thu, 19 Apr 2012 22:32:41 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> Date: Thu, 19 Apr 2012 22:32:41 -0700 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkLuNkZzWAwpXUv97ulmIDEbgNay2mMXTcMa1AjUkKCvwKil50Zv/bC6XebZOiBCTFkFpes X-Mailman-Approved-At: Fri, 20 Apr 2012 06:57:38 -0700 Cc: oauth@ietf.org, Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 05:32:43 -0000 Oops, looks like I left off the link to my own remarks about XML&JSON: http://goo.gl/v7Pjr - but they say the same thing, more or less, that MNot did. Your characterizing me as an enemy of XML is amusing, given that my name appears at the top of this document: http://goo.gl/lBjkl The points 1 & 2 you=92re reacting to are from someone else. But we agree that the choice of formats isn=92t crucial. Where we disagree is that we should pick just one, not multiple ones. -T On Thu, Apr 19, 2012 at 9:43 PM, Paul E. Jones wrot= e: > Tim, > > I do not agree that it's harmful. If I removed the WF discussion off the > table, I'm still having a hard time buying into everything you said in th= e > blog post. > > I implement various web services, largely for my own use. =A0Usually, I > implement all of them in XML, JSON, plain text (attribute/value pairs), A= ND > JavaScript (for JSONP). =A0For simple services, it's not hard. =A0I do it > because I sometimes have different wants/desires on the client side. =A0(= For > more complex ones, I use XML.) > > For your point (1): > For WebFinger, the format is simple. =A0The XRD and JRD definitions exist= and > are clearly defined. =A0I think the definitions of each are natural. =A0I= t's not > hard to produce both. > > For your point (2): > That's a bias you have against XML, no two ways about it. =A0I tend to pr= efer > to run XML through a sax-style parser and pull out what I want. =A0But, d= oing > data binding is reasonable if one is dealing with complex data structures= . > WebFinger is not so complex that it would need to be done that way, but s= o > what if developers did? =A0It's their code. =A0A lot of web services have= been > written that way, so let developers choose. > > You conclude with "use JSON". =A0By that logic, we should send the HTML5 = team > back to the drawing board and have then re-write it in JSON. =A0Oh, HTML = is a > document format. =A0Complex JSON isn't? =A0I'd argue it is whatever you w= ant to > put in it. > > In any case, I'm not going to object if the consensus of the group is to > abandon XML entirely. =A0I personally do not care which format(s) we use. > What bothers me, though, is that we put a stake in the ground a few years > ago and people were happy until *very* recently. =A0Now, we want to pull = it > out of the ground and put in a whole new one. > > Engineering protocols should involve thinking far down the road. =A0I can= not > fault anyone for having selected XML at the outset. =A0I cannot fault any= one > for wanting to add JSON support now for something this simple to implemen= t > on the server. =A0However, what I call dangerous is declaring that JSON s= hould > be the only format for the web, ignoring the significant investment web > developers have in XML. =A0The motivation for JSON? =A0Because it works w= ell > with JavaScript, in spite of the fact that nobody would want to do an eva= l > on it, so it has to be parsed like any other format? =A0What about the ne= xt > web language? =A0Would we invent a new format for that, too? > > This is like throwing out a widely deploy authentication protocol and > re-inventing that wheel, too. =A0Oh yeah... that would be what was done w= ith > OpenID Connect ;-) > > Seriously... is there no sense of maintaining backward compatibility and > rigidly defining protocols for the long-term? > > Paul > >> -----Original Message----- >> From: Tim Bray [mailto:tbray@textuality.com] >> Sent: Thursday, April 19, 2012 11:41 PM >> To: Paul E. Jones >> Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discove= ry >> (SWD) >> >> No. Supporting two different on-the-wire data formats is actively harmfu= l. >> Here are two pieces which explain why: >> >> - mnot, this month: >> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide >> - Me, back in 2009 >> >> Pick one. -T >> >> On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones >> wrote: >> > Mike, >> > >> >> There are two criteria that I would consider to be essential >> >> requirements for any resulting general-purpose discovery specificatio= n: >> >> >> >> 1. =A0Being able to always discover per-user information with a singl= e >> >> GET (minimizing user interface latency for mobile devices, etc.) >> > >> > WF can do that. =A0See: >> > $ curl -v https://packetizer.com/.well-known/\ >> > =A0 =A0 =A0 =A0 =A0host-meta.json?resource=3Dacct:paulej@packetizer.co= m >> > >> >> 2. =A0JSON should be required and it should be the only format requir= ed >> >> (simplicity and ease of deployment/adoption) >> > >> > See the above example. =A0However, I also support XML with my server. >> > It took me less than 10 minutes to code up both XML and JSON >> > representations. =A0Once the requested format is determined, the >> > requested URI is determined, data is pulled from the database, spittin= g >> out the desired format is trivial. >> > >> > Note, and very important note: supporting both XML and JSON would only >> > be a server-side requirement. =A0The client is at liberty to use the >> > format it prefers. =A0I would agree that forcing a client to support >> > both would be unacceptable, but the server? =A0Nothing to it. >> > >> >> SWD already meets those requirements. =A0If the resulting spec meets >> >> those requirements, it doesn't matter a lot whether we call it >> >> WebFinger or Simple Web Discovery, but I believe that the >> >> requirements discussion is probably the most productive one to be >> >> having at this point - not the starting point document. >> > >> > I believe WebFinger meets those requirements. =A0We could debate wheth= er >> > XML should be supported, but I'll note (again) that it is there in RFC >> 6415. >> > That document isn't all that old and, frankly, it concerns me that we >> > would have a strong preference for format A one week and then Format B >> the next. >> > We are where we are and I can see reason for asking for JSON, but no >> > good reason to say we should not allow XML (on the server side). >> > >> > Paul >> > >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss > From laurentwalter.goix@telecomitalia.it Thu Apr 19 22:49:01 2012 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 1C6F221E8042; Thu, 19 Apr 2012 22:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr9VuVIIblLy; Thu, 19 Apr 2012 22:49:00 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 86B8F21E8036; Thu, 19 Apr 2012 22:48:59 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 20 Apr 2012 07:48:57 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Fri, 20 Apr 2012 07:48:57 +0200 From: Goix Laurent Walter To: Tim Bray , "Paul E. Jones" Date: Fri, 20 Apr 2012 07:48:53 +0200 Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Thread-Index: Ac0etwcb3Q3bCrfsTWmOcjrcvQZQcQAAeLCw Message-ID: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 20 Apr 2012 06:57:38 -0700 Cc: "oauth@ietf.org" , Apps Discuss Subject: [OAUTH-WG] R: [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 05:49:01 -0000 I also would be in favor of keeping both, for the reasons mentioned. Plus x= ml is traditionally better than json at handling extensions & namespaces th= at may appear throughout future deployments walter > -----Messaggio originale----- > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] Per conto di Tim Bray > Inviato: venerd=EC 20 aprile 2012 7.33 > A: Paul E. Jones > Cc: oauth@ietf.org; Apps Discuss > Oggetto: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery (SWD) > > Oops, looks like I left off the link to my own remarks about XML&JSON: > http://goo.gl/v7Pjr - but they say the same thing, more or less, that > MNot did. Your characterizing me as an enemy of XML is amusing, given > that my name appears at the top of this document: http://goo.gl/lBjkl > > The points 1 & 2 you're reacting to are from someone else. But we > agree that the choice of formats isn't crucial. Where we disagree is > that we should pick just one, not multiple ones. -T > > On Thu, Apr 19, 2012 at 9:43 PM, Paul E. Jones > wrote: > > Tim, > > > > I do not agree that it's harmful. If I removed the WF discussion off > the > > table, I'm still having a hard time buying into everything you said > in the > > blog post. > > > > I implement various web services, largely for my own use. Usually, I > > implement all of them in XML, JSON, plain text (attribute/value > pairs), AND > > JavaScript (for JSONP). For simple services, it's not hard. I do it > > because I sometimes have different wants/desires on the client side. > (For > > more complex ones, I use XML.) > > > > For your point (1): > > For WebFinger, the format is simple. The XRD and JRD definitions > exist and > > are clearly defined. I think the definitions of each are natural. > It's not > > hard to produce both. > > > > For your point (2): > > That's a bias you have against XML, no two ways about it. I tend to > prefer > > to run XML through a sax-style parser and pull out what I want. But, > doing > > data binding is reasonable if one is dealing with complex data > structures. > > WebFinger is not so complex that it would need to be done that way, > but so > > what if developers did? It's their code. A lot of web services have > been > > written that way, so let developers choose. > > > > You conclude with "use JSON". By that logic, we should send the > HTML5 team > > back to the drawing board and have then re-write it in JSON. Oh, > HTML is a > > document format. Complex JSON isn't? I'd argue it is whatever you > want to > > put in it. > > > > In any case, I'm not going to object if the consensus of the group is > to > > abandon XML entirely. I personally do not care which format(s) we > use. > > What bothers me, though, is that we put a stake in the ground a few > years > > ago and people were happy until *very* recently. Now, we want to > pull it > > out of the ground and put in a whole new one. > > > > Engineering protocols should involve thinking far down the road. I > cannot > > fault anyone for having selected XML at the outset. I cannot fault > anyone > > for wanting to add JSON support now for something this simple to > implement > > on the server. However, what I call dangerous is declaring that JSON > should > > be the only format for the web, ignoring the significant investment > web > > developers have in XML. The motivation for JSON? Because it works > well > > with JavaScript, in spite of the fact that nobody would want to do an > eval > > on it, so it has to be parsed like any other format? What about the > next > > web language? Would we invent a new format for that, too? > > > > This is like throwing out a widely deploy authentication protocol and > > re-inventing that wheel, too. Oh yeah... that would be what was done > with > > OpenID Connect ;-) > > > > Seriously... is there no sense of maintaining backward compatibility > and > > rigidly defining protocols for the long-term? > > > > Paul > > > >> -----Original Message----- > >> From: Tim Bray [mailto:tbray@textuality.com] > >> Sent: Thursday, April 19, 2012 11:41 PM > >> To: Paul E. Jones > >> Cc: Mike Jones; Murray S. Kucherawy; oauth@ietf.org; Apps Discuss > >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery > >> (SWD) > >> > >> No. Supporting two different on-the-wire data formats is actively > harmful. > >> Here are two pieces which explain why: > >> > >> - mnot, this month: > >> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide > >> - Me, back in 2009 > >> > >> Pick one. -T > >> > >> On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones > > >> wrote: > >> > Mike, > >> > > >> >> There are two criteria that I would consider to be essential > >> >> requirements for any resulting general-purpose discovery > specification: > >> >> > >> >> 1. Being able to always discover per-user information with a > single > >> >> GET (minimizing user interface latency for mobile devices, etc.) > >> > > >> > WF can do that. See: > >> > $ curl -v https://packetizer.com/.well-known/\ > >> > host-meta.json?resource=3Dacct:paulej@packetizer.com > >> > > >> >> 2. JSON should be required and it should be the only format > required > >> >> (simplicity and ease of deployment/adoption) > >> > > >> > See the above example. However, I also support XML with my > server. > >> > It took me less than 10 minutes to code up both XML and JSON > >> > representations. Once the requested format is determined, the > >> > requested URI is determined, data is pulled from the database, > spitting > >> out the desired format is trivial. > >> > > >> > Note, and very important note: supporting both XML and JSON would > only > >> > be a server-side requirement. The client is at liberty to use the > >> > format it prefers. I would agree that forcing a client to support > >> > both would be unacceptable, but the server? Nothing to it. > >> > > >> >> SWD already meets those requirements. If the resulting spec > meets > >> >> those requirements, it doesn't matter a lot whether we call it > >> >> WebFinger or Simple Web Discovery, but I believe that the > >> >> requirements discussion is probably the most productive one to be > >> >> having at this point - not the starting point document. > >> > > >> > I believe WebFinger meets those requirements. We could debate > whether > >> > XML should be supported, but I'll note (again) that it is there in > RFC > >> 6415. > >> > That document isn't all that old and, frankly, it concerns me that > we > >> > would have a strong preference for format A one week and then > Format B > >> the next. > >> > We are where we are and I can see reason for asking for JSON, but > no > >> > good reason to say we should not allow XML (on the server side). > >> > > >> > Paul > >> > > >> > > >> > _______________________________________________ > >> > apps-discuss mailing list > >> > apps-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From gsalguei@cisco.com Thu Apr 19 23:21:28 2012 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 A3BF021F86D6 for ; Thu, 19 Apr 2012 23:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPuvbalhckf9 for ; Thu, 19 Apr 2012 23:21:25 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA8E21F86D7 for ; Thu, 19 Apr 2012 23:21:24 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3K6LNEB015378 for ; Fri, 20 Apr 2012 02:21:23 -0400 (EDT) Received: from rtp-gsalguei-87113.cisco.com (rtp-gsalguei-87113.cisco.com [10.116.61.62]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3K6LM54006329; Fri, 20 Apr 2012 02:21:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 20 Apr 2012 02:21:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E57926E-068A-484B-8D5B-DADF95DA92B3@cisco.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Fri, 20 Apr 2012 06:57:38 -0700 Cc: "oauth@ietf.org" , Gonzalo Salgueiro , 'Apps Discuss' Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 06:21:28 -0000 Mike -=20 I can get behind this approach. (Note: We already mandated JSON in the current WebFinger spec) Cheers, Gonzalo On Apr 20, 2012, at 1:48 AM, Mike Jones wrote: > To be clear, making this mandatory would break no clients. It would = require updating some servers, just as requiring JSON would. This seems = like a fair tradeoff when it makes an appreciable difference in user = interface latency in some important scenarios. If you and the other key = WebFinger supporters can agree to making "resource" support mandatory = and requiring JSON, I believe we may have a path forward. >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com]=20 > Sent: Thursday, April 19, 2012 10:39 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) >=20 > That's correct. We could certainly make it mandatory, but the reason = it isn't is to maintain backward compatibility with existing = deployments. >=20 > I think we should always think carefully when we decide to make a = change that breaks backward-compatibility. This is one change that = would do that. >=20 > Paul >=20 >> -----Original Message----- >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] >> Sent: Friday, April 20, 2012 1:10 AM >> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss' >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 >> Discovery >> (SWD) >>=20 >> Currently, support for the "resource" parameter is optional, as per=20= >> the following (correct?): >>=20 >> Note that support for the "resource" parameter is optional, but >> strongly RECOMMENDED for improved performance. If a server does = not >> implement the "resource" parameter, then the server's host metadata >> processing logic remains unchanged from RFC 6415. >>=20 >> To truly support 1, this would need to be changed to REQUIRED, = correct? >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Paul E. Jones [mailto:paulej@packetizer.com] >> Sent: Thursday, April 19, 2012 8:16 PM >> To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 >> Discovery >> (SWD) >>=20 >> Mike, >>=20 >>> There are two criteria that I would consider to be essential=20 >>> requirements for any resulting general-purpose discovery = specification: >>>=20 >>> 1. Being able to always discover per-user information with a single=20= >>> GET (minimizing user interface latency for mobile devices, etc.) >>=20 >> WF can do that. See: >> $ curl -v https://packetizer.com/.well-known/\ >> host-meta.json?resource=3Dacct:paulej@packetizer.com >>=20 >>> 2. JSON should be required and it should be the only format=20 >>> required (simplicity and ease of deployment/adoption) >>=20 >> See the above example. However, I also support XML with my server. =20= >> It took me less than 10 minutes to code up both XML and JSON = representations. >> Once the requested format is determined, the requested URI is=20 >> determined, data is pulled from the database, spitting out the = desired=20 >> format is trivial. >>=20 >> Note, and very important note: supporting both XML and JSON would = only=20 >> be a server-side requirement. The client is at liberty to use the=20 >> format it prefers. I would agree that forcing a client to support=20 >> both would be unacceptable, but the server? Nothing to it. >>=20 >>> SWD already meets those requirements. If the resulting spec meets=20= >>> those requirements, it doesn't matter a lot whether we call it=20 >>> WebFinger or Simple Web Discovery, but I believe that the=20 >>> requirements discussion is probably the most productive one to be=20 >>> having at this point - not the starting point document. >>=20 >> I believe WebFinger meets those requirements. We could debate = whether=20 >> XML should be supported, but I'll note (again) that it is there in = RFC 6415. >> That document isn't all that old and, frankly, it concerns me that we=20= >> would have a strong preference for format A one week and then Format = B=20 >> the next. >> We are where we are and I can see reason for asking for JSON, but no=20= >> good reason to say we should not allow XML (on the server side). >>=20 >> Paul >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From derek@ihtfp.com Fri Apr 20 07:18:08 2012 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 674B821F8764; Fri, 20 Apr 2012 07:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCxj+m1JRuQl; Fri, 20 Apr 2012 07:18:06 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id EF44721F8630; Fri, 20 Apr 2012 07:18:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 46C452602A6; Fri, 20 Apr 2012 10:17:59 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 10850-07; Fri, 20 Apr 2012 10:17:58 -0400 (EDT) Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 4971526029C; Fri, 20 Apr 2012 10:17:58 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3KEHrLD031999; Fri, 20 Apr 2012 10:17:53 -0400 From: Derek Atkins To: "Paul E. Jones" References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> Date: Fri, 20 Apr 2012 10:17:51 -0400 In-Reply-To: <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> (Paul E. Jones's message of "Fri, 20 Apr 2012 00:43:08 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: 'Tim Bray' , oauth@ietf.org, 'Apps Discuss' Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 14:18:08 -0000 Paul, "Paul E. Jones" writes: > Tim, > > I do not agree that it's harmful. If I removed the WF discussion off the > table, I'm still having a hard time buying into everything you said in the > blog post. > > I implement various web services, largely for my own use. Usually, I > implement all of them in XML, JSON, plain text (attribute/value pairs), AND > JavaScript (for JSONP). For simple services, it's not hard. I do it > because I sometimes have different wants/desires on the client side. (For > more complex ones, I use XML.) As an individual (and not the chair of OAUTH) I believe that the server should be allowed, no encouraged, to support multiple formats for data retrieval. I also believe that clients should be allowed to choose only one. I am fine with JSON being Mandatory to Implement. I am NOT okay with making it the only one, and I am even less okay with mandating it is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- you can convince me either way) XML, and MAY for anything else that people feel stronly about (although I feel in 2012 XML and JSON are the two best). I also feel it is okay to say that a client MUST implement one of JSON or XML, and MAY implement more. Note that this is a replay of the historical "MUST Implement" versus "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON and XML does not mean that a Client must use both (or even that a client must implement both). It is perfectly reasonable and generally acceptable to have a server that provides data in multiple formats whereas the client only supports a subset and specifies which format(s) are acceptable. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From jricher@mitre.org Fri Apr 20 07:34:32 2012 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 07EA521F8771 for ; Fri, 20 Apr 2012 07:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.319 X-Spam-Level: X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHmi2OEEXIq2 for ; Fri, 20 Apr 2012 07:34:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 819E121F875E for ; Fri, 20 Apr 2012 07:34:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4359721B17DE; Fri, 20 Apr 2012 10:34:25 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 357AB21B0019; Fri, 20 Apr 2012 10:34:25 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 20 Apr 2012 10:34:24 -0400 Message-ID: <4F9173C8.9030808@mitre.org> Date: Fri, 20 Apr 2012 10:33:44 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <59E470B10C4630419ED717AC79FCF9A906E74E@CH1PRD0410MB369.namprd04.prod.outlook.com> <4F885680.5090801@mitre.org> <59E470B10C4630419ED717AC79FCF9A9090519@CH1PRD0410MB369.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9090519@CH1PRD0410MB369.namprd04.prod.outlook.com> Content-Type: multipart/mixed; boundary="------------030309090505030906050601" X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token 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: Fri, 20 Apr 2012 14:34:32 -0000 --------------030309090505030906050601 Content-Type: multipart/alternative; boundary="------------050409080206000507060509" --------------050409080206000507060509 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit It's a difference between the front channel and the back channel. See attached diagram for a very high level overview that I've used in a few talks. The browser is for flows where you need the user and their authentication present in order to make the connection, such as the authz code or implicit flows. The idea is that you, as the client, fire off a web browser to send the user over to the authorization endpoint directly, where they authenticate with the authorization server using whatever mechanism they can. This lets you use two factor, certificates, openid, username/password, whatever. The client doesn't have to support or see any of this because it's all happening in a browser between the user and the authorization server, which probably already has a direct user log in mechanism it has access to. As has been pointed out, you can do OAuth2 without involving the front channel at all by using the client credentials, resource owner credentials, or assertion flows. None of these sound like they fit what you want to do, though. And it's trivial to pop open a browser in most platforms; the trick has historically been getting the callback from the site, which is less of a problem on mobile platforms. Side note, OAuth is not really RESTful, but its tokens are easily compatible with RESTful APIs. -- Justin On 04/19/2012 05:37 PM, Lewis Adam-CAL022 wrote: > > Hi Justin, > > There is one thing I have not understood about the whole external > browser vs. embedded browser guidance ... and that is, why is **any** > browser needed? Java for example has an HTTP library, and OAuth is > RESTful. So why is it necessary to require the web browser at all, > whether external or embedded? Why can't my native client make RESTful > API calls to the AS and RS natively? > > Tx! > > adam > > *From:*Justin Richer [mailto:jricher@mitre.org] > *Sent:* Friday, April 13, 2012 11:38 AM > *To:* Lewis Adam-CAL022 > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token > > If the mobile device has a web browser (such as a smart phone), then > this is pretty easy, and you've got a couple of options. > > One of the best options when the token is on behalf of an end user is, > in my opinion, to use the authorization code flow like this: First, > register what's called a "public client" with your server -- so you'll > get an ID but not a client secret. With that client ID, register a > custom-scheme callback URI, like "myapp://oauthcallback", and register > your app on the device as the handler for "myapp". > > In your application, to start things off, you fire off a web browser > to the authorization server's authorization endpoint. The user logs in > to the authorization server through the web browser, approves this > copy of your app, and gets redirected to > "myapp://oauthcallback?code=basdf132". Your app grabs the "myapp://" > url and plucks the authorization code off the end of it. Your app then > takes that code and sends it in the background to the token endpoint > to exchange for a token. > > Some key points: > > 1) You need to have access to a web browser on the platform, and it's > considered best practice to push the user to the external browser > application on the platform instead of embedding one. There are a > couple paragraphs in the spec's security considerations section that > talk about this. > 2) Your app is "public" because you can't publish it with a secret at > configuration time. It can, however, keep the tokens secret at runtime. > 3) You need to be very careful with how you store the tokens on the > device -- they need to be in a trusted space where other apps on the > device can't sniff them out. > 4) Another app can try to register "myapp://" and intercept your code > on the way through, so make sure your codes are all one time use and > short lived. > > None of this is just theoretically possible, people are doing it > today. What libraries and stuff you'd be after depends wholly on your > platform (both server and client side). > > -- Justin > > On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote: > > Hi all, > > I've been talking to some of you off line about this already, but I > need some help in terms of implementation. I would like to use OAuth > as a means to get either a JWT or SAML token to a client running on a > handheld device. This is something that I'm looking to prototype (as > part of a larger project) beginning this week. So, it is important to > me to understand the divide between what is theoretically possible and > what is actually possible. > > Anybody aware of any implementations out there, either vendor or open > source, that I can use for this? > > Tx! > adam > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------050409080206000507060509 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit It's a difference between the front channel and the back channel. See attached diagram for a very high level overview that I've used in a few talks.

The browser is for flows where you need the user and their authentication present in order to make the connection, such as the authz code or implicit flows. The idea is that you, as the client, fire off a web browser to send the user over to the authorization endpoint directly, where they authenticate with the authorization server using whatever mechanism they can. This lets you use two factor, certificates, openid, username/password, whatever. The client doesn't have to support or see any of this because it's all happening in a browser between the user and the authorization server, which probably already has a direct user log in mechanism it has access to.

As has been pointed out, you can do OAuth2 without involving the front channel at all by using the client credentials, resource owner credentials, or assertion flows. None of these sound like they fit what you want to do, though. And it's trivial to pop open a browser in most platforms; the trick has historically been getting the callback from the site, which is less of a problem on mobile platforms.

Side note, OAuth is not really RESTful, but its tokens are easily compatible with RESTful APIs.

 -- Justin

On 04/19/2012 05:37 PM, Lewis Adam-CAL022 wrote:

Hi Justin,

 

There is one thing I have not understood about the whole external browser vs. embedded browser guidance … and that is, why is *any* browser needed?  Java for example has an HTTP library, and OAuth is RESTful.  So why is it necessary to require the web browser at all, whether external or embedded?  Why can’t my native client make RESTful API calls to the AS and RS natively?

 

Tx!

adam

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, April 13, 2012 11:38 AM
To: Lewis Adam-CAL022
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token

 

If the mobile device has a web browser (such as a smart phone), then this is pretty easy, and you've got a couple of options.

One of the best options when the token is on behalf of an end user is, in my opinion, to use the authorization code flow like this: First, register what's called a "public client" with your server -- so you'll get an ID but not a client secret. With that client ID, register a custom-scheme callback URI, like "myapp://oauthcallback", and register your app on the device as the handler for "myapp".

In your application, to start things off, you fire off a web browser to the authorization server's authorization endpoint. The user logs in to the authorization server through the web browser, approves this copy of your app, and gets redirected to "myapp://oauthcallback?code=basdf132". Your app grabs the "myapp://" url and plucks the authorization code off the end of it. Your app then takes that code and sends it in the background to the token endpoint to exchange for a token.

Some key points:

1) You need to have access to a web browser on the platform, and it's considered best practice to push the user to the external browser application on the platform instead of embedding one. There are a couple paragraphs in the spec's security considerations section that talk about this.
2) Your app is "public" because you can't publish it with a secret at configuration time. It can, however, keep the tokens secret at runtime.
3) You need to be very careful with how you store the tokens on the device -- they need to be in a trusted space where other apps on the device can't sniff them out.
4) Another app can try to register "myapp://" and intercept your code on the way through, so make sure your codes are all one time use and short lived.

None of this is just theoretically possible, people are doing it today. What libraries and stuff you'd be after depends wholly on your platform (both server and client side).

 -- Justin

On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote:

Hi all,

 

I’ve been talking to some of you off line about this already, but I need some help in terms of implementation.  I would like to use OAuth as a means to get either a JWT or SAML token to a client running on a handheld device.  This is something that I’m looking to prototype (as part of a larger project) beginning this week.  So, it is important to me to understand the divide between what is theoretically possible and what is actually possible.

 

Anybody aware of any implementations out there, either vendor or open source, that I can use for this?

 

Tx!
adam




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 


--------------050409080206000507060509-- --------------030309090505030906050601 Content-Type: image/png; name="front channel vs back channel.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="front channel vs back channel.png" iVBORw0KGgoAAAANSUhEUgAAAtAAAAIcCAYAAADffZlTAAAD8GlDQ1BJQ0MgUHJvZmlsZQAA KJGNVd1v21QUP4lvXKQWP6Cxjg4Vi69VU1u5GxqtxgZJk6XpQhq5zdgqpMl1bhpT1za2021V n/YCbwz4A4CyBx6QeEIaDMT2su0BtElTQRXVJKQ9dNpAaJP2gqpwrq9Tu13GuJGvfznndz7v 0TVAx1ea45hJGWDe8l01n5GPn5iWO1YhCc9BJ/RAp6Z7TrpcLgIuxoVH1sNfIcHeNwfa6/9z dVappwMknkJsVz19HvFpgJSpO64PIN5G+fAp30Hc8TziHS4miFhheJbjLMMzHB8POFPqKGKW i6TXtSriJcT9MzH5bAzzHIK1I08t6hq6zHpRdu2aYdJYuk9Q/881bzZa8Xrx6fLmJo/iu4/V XnfH1BB/rmu5ScQvI77m+BkmfxXxvcZcJY14L0DymZp7pML5yTcW61PvIN6JuGr4halQvmjN lCa4bXJ5zj6qhpxrujeKPYMXEd+q00KR5yNAlWZzrF+Ie+uNsdC/MO4tTOZafhbroyXuR3Df 08bLiHsQf+ja6gTPWVimZl7l/oUrjl8OcxDWLbNU5D6JRL2gxkDu16fGuC054OMhclsyXTOO FEL+kmMGs4i5kfNuQ62EnBuam8tzP+Q+tSqhz9SuqpZlvR1EfBiOJTSgYMMM7jpYsAEyqJCH DL4dcFFTAwNMlFDUUpQYiadhDmXteeWAw3HEmA2s15k1RmnP4RHuhBybdBOF7MfnICmSQ2SY jIBM3iRvkcMki9IRcnDTthyLz2Ld2fTzPjTQK+Mdg8y5nkZfFO+se9LQr3/09xZr+5GcaSuf eAfAww60mAPx+q8u/bAr8rFCLrx7s+vqEkw8qb+p26n11Aruq6m1iJH6PbWGv1VIY25mkNE8 PkaQhxfLIF7DZXx80HD/A3l2jLclYs061xNpWCfoB6WHJTjbH0mV35Q/lRXlC+W8cndbl9t2 SfhU+Fb4UfhO+F74GWThknBZ+Em4InwjXIyd1ePnY/Psg3pb1TJNu15TMKWMtFt6ScpKL0iv SMXIn9QtDUlj0h7U7N48t3i8eC0GnMC91dX2sTivgloDTgUVeEGHLTizbf5Da9JLhkhh29QO s1luMcScmBXTIIt7xRFxSBxnuJWfuAd1I7jntkyd/pgKaIwVr3MgmDo2q8x6IdB5QH162mcX 7ajtnHGN2bov71OU1+U0fqqoXLD0wX5ZM005UHmySz3qLtDqILDvIL+iH6jB9y2x83ok898G OPQX3lk3Itl0A+BrD6D7tUjWh3fis58BXDigN9yF8M5PJH4B8Gr79/F/XRm8m241mw/wvur4 BGDj42bzn+Vmc+NL9L8GcMn8F1kAcXjEKMJAAAAACXBIWXMAAAsTAAALEwEAmpwYAAAgAElE QVR4nOzdeXRd9X3v/ffe+8zn6GiWLMm2rMGjPBsPgB1jRgf7CZDAJW6SpoEnq7Slocm6zVNu mzZJe5vphhRyUx4IQ0hoIQ/pDYECBmwSJjsesfGgyJYt2bJk2ZrHM+zh9/wh713JkgeB5fH7 WkvrWGfY0/GyP+d3vr/vT1NKKYQQQgghhBBnRb/QByCEEEIIIcSlRAK0EEIIIYQQoyABWggh hBBCiFGQAC2EEEIIIcQonDFAK6WQeYZCCCGEEEIMOGWAVkrxne98hyVLlnDNNdfwve99T4K0 EEIIIYS44vlOvkMpheM43HLLLezYsQOfz8dnPvMZHnroIfbt28fjjz+OrutomnYhjlcIIYQQ QogLaliAtm0b0zQ5dOgQPT09aJrGhg0b6Ozs5He/+x2pVIpgMIhhGBfieIUQQgghhLighgRo x3GwbZtkMkltbS0A48ePZ8eOHQCYpkkymcQwDDRNQ9dlDqIQQgghhLiyDEnAjuNgmiaJRIK/ +Iu/ACAvL897fPXq1SSTSSzLwnGc83ukQgghhBBCXAS8EWi324Zt26RSKb7whS/Q3t7O+vXr AVizZg0rV64knU5j27b3fKmFFkIIIYQQVxJNnWitoZTCsiz6+/vp7Ozk2LFjtLS00Nvbi1KK WCxGQUEBBQUF5OTkEA6H8fl8EqCFEEIIIcQVZUgNtKZpGIaB3+8nFAoRjUa91nWxWIxgMIjf 75cuHEIIIYQQ4orlBWhN09A0DZ/PRzgcJh6PAxAOh73beDw+ZORZQrQQQgghhLjSDBuB9vl8 hEIhAAKBAOl0GqUUgUCAcDhMOBz2unAIIYQQQghxpfFqoF2O4+A4DpZlYds2tm0DoOs6Pp8P wzAwDENa2AkhhBBCiCvSsAANAyHaXZHQbVfn1j3rui7hWQghhBBCXLFGTMJuWP7BD37AsmXL WL58OT/84Q8lPAshhBBCiCvesKW83ZHnW265hR07duDz+fjMZz7Dj370I/bv38/jjz8uXTiE EEIIIcQVa1iAtm0b0zQ5dOgQPT09aJrGhg0b6Ozs5He/+x2pVIpgMIhhGBfieIUQQgghhLig hgRox3GwbZtkMkltbS0A48ePZ8eOHQCYpkkymfS6cEg5hxBCCCGEuNIMScCO42CaJolEgr/4 i78AIC8vz3t89erVJJNJLMvyJhcKIYQQQghxJfFGoJVSKKWwbZtUKsUXvvAF2tvbWb9+PQBr 1qxh5cqVpNNpbNv2ni+10EIIIYQQ4kritbFTSmFZFv39/XR2dnLs2DFaWlro7e1FKUUsFqOg oICCggJycnKGrEgohBBCCCHElWLYSoSGYeD3+wmFQkSjUdw20bFYjGAwiN/vly4cQgghhBDi iuUFaE3TvKW8w+Ew8XgcgHA47N3G4/EhI88SooUQQgghxJVm2Ai0z+cjFAoBEAgESKfTKKUI BAKEw2HC4bDXhUMIIYQQQogrzbClvN3luy3LwrZtbNsGBlYn9Pl8GIaBYRjSwk4IIYQQQlyR hgVoGAjR7oqE7sNuyYYs5y2EEEIIIa5kIwZowAvOgwP04FshhBBCCCGuRKcM0EIIIYQQQojh pBZDCCGEEEKIUZAALYQQQgghxChIgBZCCCGEEGIULtkArZTig4Nbue2fb+C2f76BI20NF/qQ hBBCCCHEFeCSm0SolKK5o4mfvPYj9jdX06/1kUokmZI/g0f+7ydkhUQhhBBCCDGmfGd+ysWj P9XHs797ijd3vorpS9Pv9JNKJunp6SFmHOG3H77Jitk3AdJuTwghhBBCjI1LYgTaUQ5v7niV n/32cUzS9FhdJFNJUqkUvb292GkbvxZgxqRZ/O8vP0lOPFcWexFCCCGEEGPioh6BVkpR3bCb H7/6v2hPtJHQe+ns6SKdSmGaJn09/dhpGyft0NubIFHSxyvbXuRzy78kpRxCCCGEEGJMXJQB WilFa08Lj73+MB8e+oCEliBpJ+jp7sY0TdKpNKneNFbKwjEVPgLMnT2T7Egut865Hdu20XVd ArQQQgghhDjnLroAnTJT/H/vPctLW/8D00jTrwYmCfb29JJOpzHTFmaviZWyMTAoL60gNyeH T0y8kSVTl5FOpbHCFj7fRXdqQgghhBDiMnDRpEylFO/seYvH3/zfWHqabjpJ9iVIpVL09fZh pi3slI3ZZ6EsxbiCcRSPL2Fa1izmFy4mMyMLHR3HcbgEyrqFEEIIIcQl6oIHaKUUB5r38+NX fsCx7qP06b10d3eRSqUw0yZ9vf04aQc7bZPuNYnHMpk8s5Ki2AQWF36CrHA2oVCIaDRKOBwm EAhgGIaUbwghhBBCiDFxQQN0Z287T677V36/fwNJI0HSStDb3UMqPRCeB+qcbRzTIWAEmTVz OtmxHK4Zt4LijAkEAgHC4TCxWIx4PE48HicSieDz+SRACyGEEEKIMXFBArRpm7y46QV+teHf sDSTHtVDqi9Jb28v6dTQOmfN0ZlUWkZuXh7zcxczNWcmwUCQcDhMNBolFouRkZHhjUAHg0EZ gRZCCCGEEGPmvAZopRSb92/g0bX/QtJJ0GV3kDATpJJD65wd0yHda1GQl8/ESaVUZk5jXv4S osEooVCISCRCRkaGF5wjkQiBQACfzyfhWQghhBBCjKnzspCKUoqG1kP879ce4lDLQRJaL139 XaSSKdLpNP29Ca/O2UrZRPwRpkydSn50HFePu47cSB7BYNAr18jIyCAWixGNRgkGg15wTnV0 cvT3W9j5/z7Nyqd/Qjgvd6xPTQghhBBCXGHGPEDbjs3D//l9Nta8S1pP0W/309PdRTqdJp1O e5MDrZSNT/czuWwy2VnZLC5YzsR4mReco9HokOAcCoXQbJvWD3bR9N5Gmt7eQN+x44SDAVI9 fVg+nS/sfF8WVBFCCCGEEOfUmJZwOI7D/3j2q9Qc2UOf0Uc6mfL6OVtpCzvtkO41URZMnDCR goICZuUsoCp3HqFgyOuu4Y06R6P01R3m4OZtNL39Hl37DhAMhdB6e/FbNqH+fpKpFKlUGv+k ifQeO06ssEACtBBCCCGEOGfGLEA7joNt2+REc9H9Pnq6ukmn0yR6E1gpG9scCM95ObmUlZcz KaOCBfnXkBGOEwwGveCs9fbRtWELdb/fQvvOPQQMAyOZwpdKEk6kSCaTaBp0J1OkLROUIm2m iZsmDe9uZModq2UU+grhOI73Z3nPhRBCCDFWxiRAK6VQSpFOp/ncknvZffhDHNOht70XK+3g pB0CeoiZc2aSF8tnSeEK8qOFA/XMjiK5/yBtH+6le+dujGSKmM+H3ttHOJFEdxzS6TS9yRRo YJomqXSalGMBkEKRxCF17CiH1r9N+f+1UiYWXuYsy6KpqYmHHnoIwzAAWLNmDXPnzpUVKYUQ Qghxzo3pCLRpmqSSKVZOuY3eRDcth9vQlM7k0ilk52SzqGAZpZEyEg2NNO1bR8+uvaj2TrLC YQK9fURSJgGlMJNJUskUuq6TSp8YaQZStkUKhUJ5wRnANCAjGOD4uxsxTRO/34+u62N1qsPO u62tjSNHjtDc3Ex3dzeBQIC8vDzy8/PJzc0lHo8TCAQk1J8DSilSqRRdXV28//77wMB7cNVV VzFlyhSi0agXqoUQQgghzoUxH55TSjExs4z8WBGzZzkYGFT6Kig45KP7lfVsaWwiFggRSqWI OxBMm9itHeiaTiqZpPdEWYZpW6TsgVHmJM6QwJzWFP5wmNyMbPLzxxFEI1AyjqoHv4ZlWd6I +FgFVvfDwpYtW3j++eeprq4mkUh4JQWBQABdH1hmPBgMMnnyZFatWsXSpUvJyMg4p+HeNE0e e+wx6uvrvftWrlzJihUrLssg6TgOlmXR39+PUgrLstB1nXQ6jWmaOI5zWZ63EEIIIS6cMQvQ mqbh8/kGumiEwtySfROv7HuW0KZjWB1NtNsOYcsimjYxzG6CaNimRU86jaFp9KZTpJWNjk4C myQOGhpJHJI4hIMhorEMCguKiRp+9KxMjKkV+KeUE6yYRDw7GyM3G9u2h9TGnmumabJhwwYe e+wxDh06NLAEuWl6+3UcB03TUEoRCATw+/1s3bqVDz74gKKiIu68805uv/12IpHIOTmWo0eP 8uKLL5JIJAgEAvT399Pd3c2iRYsu29FYpdSw99j90CSEEEIIca6NSYDWNA1d1/H7/V4Luu3f +A7jLAtSKQKAZlpgmmiaDpZFIp3GQMNUNklsNLQTo8wDZRo+n49INMb4/EKywhnowSBG5SSM KeX4ykvRoxF0XccwDILBoLewylhOJkun0/z7v/87P//5z+nu7sY0TSzLorCwkOnTp1NUVERh YSF+v5/29naOHz/Orl27qK+vR9M0TNPk4YcfZvv27Tz44IPk5OR85GNVSmGaJmvXrqW1tRWA np4efD4fe/fuZc+ePSxYsABd16V0RAghhBDiYzgvI9CRSIS88cW07d4L6YGQqds2PiDp2Fgo NBTpE7XMAKauEYxGKMzMJzcnBx86Rul4jGmV6OWlGLnZXmA2DAOfz4ff7ycQCAxpfxcMBsek /jmZTPL973+f119/nWQyiWVZRKNRPv3pTzNr1ixvtNfdt1IK27a59dZb2b17Ny+99BKHDx8m GAzyzjvvkEgk+Na3vkVubu5HCriO45BMJlm3bh2apnmj30opkskkb7zxBlVVVd6HiouRO2ps mibJZJJoNCqTAIUQQghx0RnTAK1pmhduJy5eSHL/Qbq7OvGhYeKQRKEDqRM1zdFIlMxYnILC IkJKRy/Mxze1AqOyDKNkHPqJQDo4MLuhORAIEAwGvZ9QKEQ4HPYC9LkMjalUil//+tesXbvW q3XOzs7m/vvvp6ioyNt/MBj0OoDYtk06nSaZTDJv3jwmTJjAE088wf79+wHYsmULjz32GF/7 2tcIh8OjPibLsqipqeHw4cMopbyaa7e8Ydu2bfT09BAOh8/bhMrRME2T999/n2eeecYbzf/h D39IaWkpgUBgVNu6WD8gCCGEEOLyMKbDe26I1jSNvHmzaV67nrbjTfThYKII+QNEYhmUFZaQ 4QugxzMwppRjTC7HVzYB7UT3DDcw+3w+r4745MDs3ueGand573Pdws40TY4cOcIzzzzjhedw OMxf/uVfMn78eGKxGLFYjEgk4i0zrmkalmWRSqVIJBL09fXh9/u57777ePTRR6mrq0PTNF57 7TWuuuoqVqxYMarQ6I7a/vrXvz7RF1tjypQpWJbFvn370DSNpqYmNmzYwKpVqy66UWh39Lyh oYHt27d772F390DvcJ/Pd1GGfiGEEEJcmcb8+3G3HjpaPomQA6GcbMZl5pAdi2P4AxgVpRhT KgZuM2KnLMs4eZTZ/d0Ny25g1nXdG3E+1/XPbsu073//+zQ3N3v333777UyYMIHs7Gyys7O9 0gP33GGgE0c4HCYjI4P+/n6vjd1/+2//jR/84AfYtk0ymeTJJ59k9uzZFBQUnPWEP9u2aWtr Y/v27cBAIF26dCmpVIqamhqvNOLtt9/mxhtv9EbGLyaWZZFIJLxOGn6/f2Cpd9u+0IcmhBBC CDHEeQnQhmEQimdQ8Gd/gvH0cwRuWIZePhEjP3fEwHyqsgz3scEjzG5gdoOqG5jHYoTVNE1q a2vZvXu3t4+cnBwWLlxIVlYWubm5xGKxU05edEsrBreumzp1Ktdddx3r169H13UOHjzIO++8 w6c+9SlCodAZz8MdfX7rrbdob28HIDMzk7KyMjRNIzMzk56eHnRdZ/fu3dTX11NVVTXqAD24 o8XZXtuTu2Cc6nXuqpVuJw33eW4dt9vJZLT7H+l4TNOku7ub3t7eIR92hBBCCCHO1pgnB7cb h6+viVi4DueL8zCtLrTELnyNBoahE/D78PsMgn4fAb+PYMDn3efe+gwdQ9cxDB39RDhVGjia hsNJoSrdhzL7CC7/H+csSDsnVkBct24dvb29Xmu6T33qUxQUFJCZmUk0GsXv959yn4NHxSOR CJZlkU6nWbRoEevWrfNGijds2MBNN91EIBA4Y9B1yx/efPNNr+Z58eLFZGcPTLK85ppreO21 11BK0dvby5tvvklFRcVZl0VYlsX777/Pyy+/7J3D3/3d352xf7VlWbz11lu88cYbABiGwTe+ 8Q3C4bB3TrZtc+TIEX784x/jOA5Hjx4dcq2efPJJsrKyhpScZGZm8rWvfY1gMHhW7607efPo 0aM89dRTVFdX09bWRjKZJCMjg7KyMlavXs2KFSsIBoNn3J4QQgghxHmpgTasPtQvbyOc9GMn wXLAp0PA0Aj4IGhoBIyB3/0G+A3w6RqGBoYOujbwowFeZtI0FKBO3Oeo/3pMKTBVAmXbhK7/ xjkJ0Y7j0Nvby4YNG4YE4cmTJ3sdP04Xnk++LoZhEI1G6e/vp7y8nJKSEo4dO4bjOOzZs4fm 5mZisdgZJ0Dats3+/fupq6sDBj6wXH311d5rFyxYwKuvvupNJty8eTNf+tKXzmoyoW3b9Pb2 Ultby5tvvumVoTQ1NVFeXn7K1RQty/Jet27dOvx+P7FYjKNHjzJ+/HhCoZDXHaStrY333nvP qxN3t5dMJtm1a9eQbxgsy6KsrIyuri6ys7PPWCfuLnDz+OOP89JLL9HW1uadFwy0+WtpaWHr 1q3s3r2bv/zLv5QQLYQQQogzOj/fXSe7iIRC+Nq6iFoDodfQGAjNFgR9A7/7T4Rlww3MJ0Kz UqDrGqNZF0OFDezOw9i2fU4mElqWRUNDA01NTd59eXl5FBQUEIlERr00t67r+Hw+otEoWVlZ VFRUeHXVHR0dfPjhh5SWluL3+0+5DXdU/De/+Q2JRAJN0ygvL6e4uJh4PI6maVRUVDBlyhQO HDiApmkcPnyYLVu2cN11151xMqFb851MJr3yh0AgQCKRwLKsUwZY93XpdNoLsUqpYTXNbt1z WVkZ6XQay7I4ePCg10GkrKxs2LYnTJjgbfd03P09+eSTvPzyy/T09OA4DvF4nLy8PDo6Oujo 6MC2bfx+P7/+9a+ZN28ey5YtG3XXDyGEEEJcWcY0QLujnpZlETR0UkmFfiL3+DTQdXA0SKqB kebUidcNGmT2bgeW4j77ffuUjs+yMUzTG/H9qNxz6OrqIplMevdXVFQQj8e90dzRhnTDMAiF QgQCAXJzc4c8VltbSzqdJhQKnfLYHcehvb2dLVu2eL9fd911ZGZmkpGRAQyM5F577bXs378f wzBwHIff/va3XHPNNWc1mdAtCzn5vjNx65oHXxN3O4Nv8/Ly+MpXvoJpmmzdutUbSQ+Hw3zx i18kKyvLe72maYRCIe+1p1tp0LIsfvWrX/HKK6/Q1dXF0qVLWbFiBTk5OQSDQRzH4fe//z3P P/+81yHl5z//OQsWLPBq8oUQQgghRjLmAdrtf+zTFT1JcCOPW46hMTwwD9/QiSedKi9pg57D wIh1PAyxdBp9UBu0jzP5LJ1O09LSguM43rYyMzO91nofpc2aG+z9fj+ZmZleKFRK0dLS4o20 jhTm3BHhd99911t5MBaLMW3aNMLhMJFIBE3T6O/vZ86cOUSjUW+UeseOHTQ3NxOJRC5oUHQX 2olGoySTyWHX0OfzDftw4q4weabrvW/fPjZu3IhlWdx///1Mnz6dUCjkjbrbts0nPvEJDh06 xPvvv++Vwhw8ePAjTbIUQgghxJVjzAK0GwQdx8FM9RHSktR1nnjwRODVdG3wr16QHmVeHvH5 lbkaWU3vYZqmN4r6cQK0ZVm0tLQMuT8ej3udQD7qtt1Sjry8vCH76+np8UoeRiq1cByHVCrF 66+/PmTyYEFBAeFw2Cv9CIfDFBYWsmTJEtavX49Sio6ODt566y3Gjx9/wXosa5pGIBAgKyuL YDDo9cZ2zx8gFAqRk5NDOBz2zt8wDC/4n+qaK6VYv349mqbxta99jYqKCqLRqFdqo+u6141j 3rx5vPfee96HpGPHjjFlyhT8J3qQCyGEEEKcbMxroB3HwcooJR0u4qYVR0+sPTjGNIWmFE1L f0yObZ/2q/6z4Qbo1tbWIaFtcL/nj3yoJ0ahs7Ozh9yfSCSwT3Pstm1z8OBBamtrve0sWbLE C4ruCKq7rPnChQt58803vQ82Gzdu5O677yYUCl2wAO3z+YjFYl5njpNHfd2R+YyMjCHtCQe3 LTwVy7K47777qKysJDMzk6ysrCETPc0TpT2Dl053HIe+vj4syxqbkxZCCCHEZeG8NcD9cPFT 7KiuxbJMHPvMNbQflaZpGD6DjIw412RMOifbdHsRu8HKDVxuCPu4ExQNw/CWHB9836kWEXFH n1966SX6+/vRNI3i4mImTJjg1VS72woGg0QiEaZOnUpZWRkNDQ3ouk5tbS27du1i8eLF53y1 xrM1eNGbkY7BHZ0f7Wiw4zjcfvvtzJ07l+zsbK8/txuevcV9TkzgHLxtt3b7437oEkIIIcTl 67z0gXaANd/5BQHNxgBwnKE1FyfXZHwsAwGpz3T4f2yDL64uOmdt7Nz2a+6CKF1dXedk9Nat VR5cZpKVlXXKEOe21Nu0aROapuE4DjfccAPxeJxIJDJkYRB3omIkEmHZsmU8++yzXv30unXr mDdv3ln3VB4r53rfuq4zbtw4MjMzycnJIR6Pj/hNgVt/Pvj+kSZNCiGEEEIMNmYBenCv5Lae BLo/SHfCAscGzRhdYB5W5HzSHQNtOgY3icbn97Onse1jTyAcLBKJDPm9p6fnY29zpG1pmkZ2 dvaIx+yG3w0bNtDS0oJSilAoxMyZM4lGo8NGsnVdJxgMkpGRwbx58/jVr37ljZxv27aNzs5O IpHIZVXv69ZXx+NxYrHYiKPbY7HUuxBCCCGuDOdlBNrn8xGORmnv7wG0EyPQJ1Y/GcHJeVnT NJQzaBKgG5bVoCFs5b5q4Cek+fD5g154Phd1yoWFhV4XDncy3rkYsXTb0Q0+xpNLCwY/N5VK 8corr2BZFkop5s6dS39/P0eOHKGrq2vYaKtlWXR3d5NMJqmqqmLbtm3ouk5LSwvvvvsud9xx x8eu5T7XzkVZjNsC8GI6LyGEEEJc+sY8QLut7DRfADOR5NS9Nc7lTiHgM07kavWxu3C4E94K Cwu9bSil6OzsPCf1srZtU1NT4wV9pRTZ2dkjhj/btjl8+LA3eTAYDLJr1y727Nlz1vsLhUJe +H777be59dZbT9tv+lI0+EOTBGghhBBCnEvnpY1d2rSwHA1S/SM/+eQSjJNHmIeVaAzb2Ukj 0oAT5A+NbV5QPBcBety4cZSVlVFfX49hGHR0dNDU1ERBQcFH2u7AoQ+s2nfw4EHvvkAgwKRJ k4b1l3ZXHnzllVfo7u5GKUUikfhI+zUMA6UU+/bt48CBA8yaNeuyCtBCCCGEEGPlvLSxy8sI 4wAlU6cQPE+ltikHPnvN9HNSYqFpGsFgkEAgwKJFizh48CCGYdDX18eWLVuYOXPmRw7olmVR X19PV1eXd9+MGTPIy8vzAvTgNmv9/f2899573kj1okWLKC4uHtU+m5ub2bhxI36/n76+Ptau XcvUqVM/8oIwQgghhBBXkvPSxi7gM/jl/Sv5oOYQtpk+VenzOaFpYOgGwXCIJdMnnJOOCrqu ex0bZs+ezfPPP+/VQm/ZssXrpzy4+8XZcEeUf/GLX5BOp737Fi9eTDAYHNK+zZ08uGnTJo4f P45SikAgwKpVqygsLDzriZK2bXPs2DE2b96M4zhomsbWrVvp6+vzVv07m+M+HfeaHz58+Izb EkIIIYS41JyXSYS6rvPwP/yCrq5O0NTYtgnTAKVh6D5K//4eioo+fhs7dxJhKBSipKSEhQsX smXLFgzDoLq6mpdeeonPf/7zow7QlmWxY8cO9u7dC+DVPk+ePJlAIDCkxZobtl9++WVM0wRg +vTpFBcXE4vFCAQCZzxPt5e13+9nzpw5fPDBB+i6TmNjI5s2beLmm28+7WRCdwlsN+yPxC3b ef3119m8efNHHpl3z1cIIYQQ4mIz5m3sdF2nq70HK+VgOBEcxz5RrjyaYDW0L8fwEmntpO1p +HUfH2yoYdE188/ZYieRSIRIJMJtt93G3r17SSQSaJrGSy+9xMKFC6mqqjrrEO04Dt3d3Tz6 6KPedhzH4d577yU/P3/IaoIwMHLc1NTEH/7wB+++6667zut1HAqFzniOSimSySSapnHttdey bds2rz78rbfeYvny5QSDwWG10MFg0PvQY9s2vb29p10hcevWrTzzzDPevs6Wux9N00in0zQ3 N5/1a4UQQgghzpcxL3jVNA2/P0A0GiPZlyKVMEn2pUknLJJ96bP6SfVb3m2q3yKd+K/bgT+b 3q37Y9sKv88/ZLW7j0PXdcLhMJFIhAkTJvCZz3wGy7KwLIujR4/yzW9+k127dp1y9cDB3PD8 9a9/nX379gEDwfOmm26ioqKCaDRKNBr1unCcPHkQIDc3l8rKSjIyMsjIyPBec6afeDxOPB5n xowZ5OfnezXiu3btorGxcdjxuz2pB08K3bx5szc5czDbtvntb3/LP//zP9PR0cGiRYvO+vpq mkZGRsaQCZ+1tbWyqIkQQgghLjpjHqDdZbB9RgAzbWGmbSzT8W7P5sdM2d7tiD/pQbdpGzNl oRzQNcMLZOdiIqHP5/MW51i2bBkrVqwgnU6TTqdpbGzkH/7hH3jjjTfo6ek57Qjt73//e77y la+wc+dOlFJYlsW0adO4+eabicfjZGRkDFkd0HEcEokE77zzjjfavmzZMrKzs72lu30+H4Zh nPHH7/cTiUTIyspi2bJlXoDu6elh3bp1pFKpITXOhmFQXFxMXl6e99zNmzezfft20uk0juNg miZHjhzh7//+7/nHf/xHjhw5wr333jvqyY1FRUVkZ2d7+9+4cSM1NTVn9aFkMAndQgghhBhL Y9rGzr21LAtNafQl3dX2hgYcDQ2FQjuxNKH7Z3XieSc/PmxfJz0fNEc67ZAAACAASURBVMKm n7aW/+rT/HHa2LncMo54PE4qleLuu+9G13XWr1+P4zg0NzfzT//0T0yePJkVK1ZQUlJCXl4e wWCQ+vp66uvr2blzJ3v27KG/v98bwV6xYgWrV68mPz+fzMxMMjIyvNFn9/rt2LGDY8eOoZTC 7/ezYMECYrHYqPo3uyU1wWCQaDTK/PnzefHFF73JhBs3buRzn/ucN5lw4NsDPzk5OaxatYqn n34aXdc5duwY3/zmN5k6dSpZWVkcPnyYlpYWurq6SKfTrFmzhpkzZ/Lee++N6tpmZmayatUq fv7zn6PrOq2trXzve9/js5/9LOXl5fj9fjo6Oli2bNmo682FEEIIIc6VMU0h7lf+/qAPpWDG zOlY1vmZGBYOxhg3PvecLHTicgNlZmYmtm3jOA5r1qyhtLSUtWvX0tjY6E0srKurQ9d173mW ZXmj8el0Gtu2icfjrF69miVLlpCVlUV2djaZmZnDJg+mUilefPFFEokESilmzpxJUVERkUiE QCAw6nMIBAJEo1EmTZrE9OnTqa6uxnEcDh48yI4dO1i6dKkX4P1+P8FgkGuvvZbdu3ezefNm bNvGNE127tyJruuYpkk6ncbv97NmzRoWL17snYP7d+BMfD4foVCIpUuXsnv3brZt24Zt2xw9 epSf/exn5OfnU19fT1VVFfPmzfM+ZJzMtu2P9EHpo75OCCGEEFee8zKMF44E+eJfr+TDLfvR 9LMLVB+V2zEj4A+w+Lo556R8YzB3BDcrKwuA9vZ2rr32WubPn8+HH37Ihg0bqKmpoaenB9u2 0XUdv9/vBWm/309hYSE33XQTVVVVZGdneyUV7p8Hr0Dotp3r6+ujrKwMpRTXX3890WjUa503 muDnXp9wOOwF1mQy6T1WXV3NVVddRTAY9I49Go2SkZHBn/zJn1BUVMTGjRvp7Oykp6cHv99P PB5n/vz53HrrrRQUFBAMBgeWbw+HvWPOzc097TH5/X5isRgZGRncc889TJgwgQ0bNtDV1cXh w4c5dOgQkUiEcDhMIpEYNskSoKysjFQqhWEYBIPBs74mlZWVpNPpgb83o/xAIoQQQogrj6bG qGDUHXlMJpO0tbVx7NgxOjo6SKVSo65pHQ23VjkWi5GXl0dBQQHxeHxIT+VzwbZtUqkU3d3d dHZ20tvbi2mamKZJV1eXd39LSwumaRIOh8nMzKS4uJh4PE4kEhkSGjMzM4eFZ6UU/f39tLS0 0NLS4gXdSCRCYWEhubm5Z9V942Tu6ofHjx+npaWFRCKB4zgYhkE0GqWoqIicnBz8fv+Q97Ct rY1EIkE6naarq4uuri6vpCUcDnvXPRqNopSiq6uLvr4+HMchEAiQn59PYWEhkUhk2Hth2/aQ /SSTSUzTpLu7m46ODkKhkFfeMnHiRK80xu0K0tzcTFvbwMqThmEQj8e9a+33+0d8/3p6emhu bqajowPTNPH5fGRmZjJu3DiysrJkZUYhhBBCjOi8tLELBoPEYjGvfOF8jEC7HTPc4Hyuv553 RzmzsrIIBAJEIhH6+/vp7+8nFAqRn58PDJ3Q5l4Tt1whEokQi8WIxWL4/f4h4fnk17q1zm4d djQaHVLqMRruNcrIyCCZTOLz+bwPNe4IrPseDR5x13Wdrq4u7xwLCwu957hlIbFYjEgkQiqV wjRNr4uI3+8nEAgMO8eRrqe7n2QySTAY9K6lpmnDRt0H9+iOxWJegHbb8Z2up7X7PsRiMUzT 9LYjwVkIIYQQpzOmJRxuSIlEIiilCIVCmKY5pl0S3NDuhlq3FGEs6lvdgOaWKyQSCZLJJMlk 0utY4Z7r4A8Ufr+fcDhMOBz2QuVIo+NuOHQnC7rbCgQChMPhjxX03NFmt4vG4ON0JxG6Ey/d 0O7z+QgGgyQSiSGvce8ffL3dcO8u+uJu93ST/9y/K36/n1AoNGw/bpgfXL4xuC59cL9qdxun ukZuLXhmZqZ3bd1tfZRRfSGEEEJcOcashMPlOI436cyyrDEt33C5oc/v93vt3cY6ELkTBN3g PHji4OBjcsOy+/uZFnlxr9/JI9mnCt2j4Xb4GGmU3O2fPdKxuOc00ocDN7AqpYYdt/v42Sz4 Ytv2iH9XBu9ncKnL4ONyn3ema3S6152LxXeEEEIIcXka8wDtbv7kEdmx5gat8x2EBrfvG2kE enDpwWi36TqX5zPS+3G67Z/u/Tv5dR/nuEezn4+zr7G8tkIIIYS4PI15gHZdiMUtLoYwNDhA CyGEEEKIS995C9BCCCGEEEJcDsZ8KW8hhBBCCCEuJxKghRBCCCGEGAUJ0EIIIYQQQoyCBGgh hBBCCCFGQQK0EEIIIYQQoyABWgghhBBCiFGQAC2EEEIIIcQoSIAWQgghhBBiFCRACyGEEEII MQoSoIUQQgghhBgFCdBCCCGEEEKMggRoIYQQQgghRkECtBBCCCGEEKMgAVoIIYQQQohRkAAt hBBCCCHEKEiAFkIIIYQQYhQkQAshhBBCCDEKEqCFEEIIIYQYBQnQQgghhBBCjIIEaCGEEEII IUZBArQQQgghhBCjIAFaCCGEEEKIUZAALYQQQgghxChIgBZCCCGEEGIUJEALIYQQQggxChKg hRBCCCGEGAUJ0EIIIYQQQoyCBGghhBBCCCFGQQK0EEIIIYQQoyABWgghhBBCiFGQAC2EEEII IcQoSIAWQgghhBBiFCRACyGEEEIIMQoSoIUQQgghhBgFCdBCCCGEEEKMggRoIYQQQgghRkEC tBBCCCGEEKPgu9AHIIQQY82yLFKpFKZpYpomtm1jWRZKKQzDwOfz4fP5MAyDQCBAOBy+0Ics hBDiIiYBWghxWbIsi5aWFlpaWvjwww+pqamho6OD48eP097eTmtrK6ZpEo/HycvLIzs7m9zc XEpKSpg9ezZlZWXe/UIIIcRgmlJKXeiDEEKIc6WxsZHDhw+za9cufv/737N161YA3H/qTr4F 0DRtyC1AQUEBixcvZtGiRVRUVFBRUUEkEjlfpyGEEOIiJgFaCHFZ6OnpYePGjbz44ots2LAB x3FwHIeP+k+cpmleoC4pKWHFihXccMMNXHXVVefysIUQQlyCJEALIS5piUSCF154gddee429 e/d6wflkSikvULs/MDQoa5qGYRjDXus+JxaLsXz5cu68804J0kIIcQWTAC2EuGRt376dhx9+ mL1795JMJocEY5dt2yilyMnJoaSkhNzcXDIzM8nOziYUCtHR0UFnZycdHR10dHRw6NAhkskk Pp8PXR/aqEjTNJRSlJSUcN111/HAAw8QjUbP5ykLIYS4CEiAFkJckl5++WUefvhhmpubAYYF Z6UUhYWFLFq0iKVLlzJ58mQCgcCQjhu6rnudOdLpNLZt09bWxo4dO9i4cSN79uwhnU4P27c7 Ur148WK+/e1vM27cuPNyzkIIIS4OEqCFEJeUdDrNT3/6U5599lm6u7uHPe7z+ZgzZw5//Md/ TFVVFcFgEL/fj67rI5ZwnFwnrZQinU6TTqfp6urizTff5De/+Q2dnZ0jloZMmTKFf/zHf2TG jBnDRqyFEEJcniRACyEuGf39/XzrW9/ilVdeGRZ6fT4fEyZM4L777mP58uX4fL4hdc/u89z7 3N8H3w8MCdmulpYWnnvuOd5++226urqGHVd+fj4PPvggN9xwAz6fdAcVQojLnQRoIcQlIZVK 8dhjj/H4448PCbe2bZOdnc2nPvUp7rnnHnJzc0mlUgBDgrL7Gtu2vftOfuzk8Dz41ufzUVtb y49+9COqq6tRSg2ZfJiVlcXf/d3fsXLlyrG+FEIIIS4wCdBCiIuebdu88MILfP/73yedTnvB 1rIsJkyYwJe+9CU+97nPkUwmvYA8Ung+1Yj04OePNDrt3uf3+zly5AhPPfUU7733HqZpemUb mqYxceJEHn/8ccaPHz/m10QIIcSFY3zzm9/85oU+CCGEOJ3333+fH/zgB/T09AwJz9OmTeOB Bx7g05/+NIlEYlgYHmk0+eSAPNJ9I4VnpRSWZZGZmcncuXNJp9McOnQIy7K87fT09NDT08PC hQsJBoNjczGEEEJccDICLQRQV1fHY489Rn5+Pg888ACGYQxZle5il0gk+O53v0sikeDBBx8k Kyvrkjr+0/nggw/46le/Smtrqxds0+k0V199Nd/4xjcoLy/3SjZGO8J8qlrokSYYDi4Bcf9+ vPXWWzz88MNDOnVomsZtt93G3/zN35CRkTF2F0YIIcQFc0XNdunt7eWBBx4YMlJ1KqZpcscd d3D33XfLpKArwKZNm/je977HrFmzWL16NeXl5fj9/vN6DK2trfzpn/4pWVlZPProo/j9/rMO wU1NTTz55JN0d3ezePFiPvnJT14Wy06bpsmPf/zjIeHZsiwqKir4yle+QllZ2ajC80jLeI8m PA8+Bk3TWLZsGc3NzTzzzDNeKYdSildffZVly5Zx8803S2cOIYS4DF1RybC9vZ033niDo0eP evcNHoU6eQUyTdNYsmQJpaWlEqKvEIlEgv379zNx4sQxC9C9vb20tbUxfvz4IX/n6uvreeml lxg3bhw7d+5kxowZRCKRsw7RhmHgOA779+9nyZIlhEKhSz68rV+/nq1btw4Jtbm5ufzVX/0V c+bMwTRNYOQe0Kcq5zhdQHYNbld3qvpp9zmf/OQnOXr0KGvXrvX+nbAsi5/+9KcsWrSInJyc c3Q1hBBCXCyuqFQ4ceJEXn75Zd59913a29tRSrFp0ybWrl3LxIkTWbNmDcFg0AssJSUlHD9+ nPHjx0uAvkIopTBN84zfUHxUiUSCu+++m127dvHDH/6Q22+/3Qvq5eXlrFmzht7eXo4cOUJZ WRnhcHjUpRimaY7Yr/hSk0wmefzxx71JgQC6rvOnf/qnXH/99d4Kg6drPzdSvfPg5w5+bKQW d6cK2IPvj0aj3HXXXTQ1NbFr1y7vg0xNTQ2vvvoqf/RHf3TJf5ARQggx1BWXCmfNmkVhYaFX xqFpGmvXrkXTNCZNmsTixYvJyMhA0zR0XScrKwu/309LSwu7du2irq6OwsJCFi9eTF5e3pBw U1NTQyqVYubMmRw6dIjdu3dz/PhxFi5cyMyZM9F1nerqanbt2uUt9lBeXj5kGzt27CAWizFp 0iT+8Ic/sGfPHgBmzpzJ9OnTh/1H3NfXR21tLX/4wx9IpVJUVlYyZcoUcnNzh2y3oaGBlpYW qqqqaGhoYPfu3ei6zurVq9F1nePHj1NXV+ctYzxlyhQWLFgwZBS2u7ubAwcOUFJSgq7r7Ny5 k7q6Om644QY6OjqYNGkS2dnZwwLfBx98QHZ2NqWlpacNg93d3Rw8eJCamhr6+/sZN24cM2bM YOLEiWiaxuHDh2ltbaWqqorDhw+zZ88e/H4/n/zkJ9F1Hdu22bdvH3v27KGnp4fp06ezcOHC Yd8sAFRXV7Nnzx5SqRTTp08/beBsbm7mww8/pKGhgeLiYq6++moyMzOHnMvevXsBmDZtGg0N DezatYve3l6mTJnC3LlzvfftwIEDtLa20tDQwG9+8xv8fj+zZ8+mrKyM7Oxs/uzP/oy6ujoK CgoIhUJomoZpmhw8eJDDhw9z5MgRcnNzmT179hmv56Xu+eefp66uzvvdsixmzJjBjTfeiK7r WJZ12sVQTlXffKrR5cFONfnw5Pvdn3HjxnH77bezb98+TNP0lvx+4oknuPnmmykoKDin10YI IcQFpq5Atm0ry7KUZVnqxz/+sQLUpEmT1JNPPqmOHTumTNP0HnccR+3evVvdeOONyu/3K0Dp uq4mTpyo3nnnHWVZllJKqfr6elVaWqoyMzPVt771LTV37lwFKEDl5eWpn/zkJ+qRRx5R5eXl 3v1FRUVq7dq1yjRNpZRSW7duVcFgUFVWVqr//t//uyouLvaem5ubq77zne+o/v5+5TiOUkqp trY29cUvflHl5+d7zwuFQmrRokVqw4YN3rEppdRVV12lgsGguu+++7xjmzVrlmpsbFS//OUv 1fz581UgEPC2E4vF1B133KG6urq8/d1///0qHA6rFStWqNWrV6tAIKB8Pp9aunSpCofDavny 5aqlpUXZtu3t95FHHlGhUEitWLFCtbe3D3lssNraWnX77berrKws7xgANXPmTHXw4EFlWZZa sGCBCgaD6s///M/VnDlzFKBmz56tGhsblWma6qGHHlKVlZVDzuHOO+9ULS0t3jk4jqO++93v qtLSUu95+fn56rOf/awCVEVFhfo//+f/qL6+PqWUUps2bVKf+MQnlM/nU4AyDENVVlaqLVu2 eNe3pqZGFRYWqsLCQvU//+f/VPPmzRuy7e9+97sqmUyqAwcOqOLiYmUYhgKU3+9XwWBQzZw5 U7W3t6tt27apaDSqJk2apBobG1U6nVY9PT3qtttuG/J3AVAlJSXq7bff9v7u1NbWqokTJ6po NKq+/e1vq8OHD5/yWl8Kurq61KpVq1RVVZWaMWOGmj59upo7d656+OGHlVJK9fX1qd7eXtXb 26u6u7tVd3e36urqUp2dnaqjo0N1dHSotrY21draqlpbW1VLS4s6fvy4On78uGpublZHjx5V TU1NqqmpSTU2NqrGxkZ15MgRdfjwYXXo0CF16NAhVV9fr+rq6lRdXZ06cOCAOnDggKqtrVX7 9+9X+/btUzU1NaqmpkZVV1ermpoatWXLFvXnf/7nasqUKWrGjBnezyOPPHKBr6YQQohz7Yps Y+eOLuu6zpYtW3j11VfJysriuuuuY/r06USjUe/xzs5ObrjhBj744AOqqqpYtWqV9/Xszp07 Wb58OTk5OXR2dvKLX/yCtrY23n//fQzD4BOf+ATpdJqmpia2b9/O2rVryc3NZdGiRfT09NDc 3ExdXR033XQTGRkZNDQ08Nhjj5FOp9m4cSOlpaXMnDkTGJgktm3bNioqKpgyZQqmaXLrrbfy 8ssvk52dzdKlS1m4cCFdXV3s2bOHtWvXcs0111BUVISu6zzzzDPU19fz4Ycf4jgOCxcuJBQK UVFRwXvvvcfevXu59tprufbaawmFQjQ0NFBXV0dRUREzZswgEAiwbt063n33XRobG6mvr2fe vHnk5eWxaNEitm3bRktLC8XFxd7zu7q6+Nu//VsOHTrEXXfdRSwWo7i4eFg5zPHjx1mxYgUb N24kHo8zZ84cli1bxrhx43Ach8rKSkpKSnj++eepr69n586dKKVYuHAh4XCYiooKduzYwQMP PICmadxyyy3MmjWLxsZGtm/fjuM4LFmyhEAgwK9//Wv++q//mr6+PqZNm8bKlSuxbZt33nkH y7LIzs7m5ptvprKyko6ODm688Ub27dvHvHnzuPnmm0mlUtTU1LBnzx6uv/564vE4ra2tPP30 0/T29vLOO+8AsHDhQvx+Pw0NDRw8eJBZs2ZRXl7OwYMHaW5u9kbIp06dSmlpKUVFRWiaxlNP PUU4HGb+/PkUFBTQ3d3NI488QmlpKddddx0zZszg+PHjHD16lLq6Oq6//noyMjLo7OzkmWee IZFIsHTpUubOnUs8Hr9kR6jXrl3L66+/7tU4O47DrFmz+OpXv0owGDxtr2f3fjXC6PJII9Xu 7ckj02rQyPPg+07ennsbjUbx+/1s3brVG4WGgbkXd91114jfhAghhLg0XXElHKP1/PPPU1tb S1VVFV/+8pcpLi5m5cqV3H///ezdu5c33niDoqIi7z9V0zSZNGkS9957L2VlZRw4cIC//du/ pbm5mauuuoovfvGLFBUVMW7cOJ588kmOHTtGbW0thYWF3j5N0+Tmm2/mU5/6FLm5ufT29vLg gw/S2NjI008/zbXXXkt1dTXbt28nGo3ymc98hiVLlpCbm8ttt93G17/+dQ4fPsy//Mu/8Mgj jwz5+jgvL4977rmH6dOnk52dTSwW44EHHuDOO++ktbWVSCSCrut8+ctfpra2lj179tDS0kIo FPLO0e/3c8cdd3D99deTl5eHZVls2LCBbdu28dprr7Fq1SrC4TCbN29m69atTJ48mZKSEnJz c0cMEf/2b//GgQMHCIVC3HnnnVx99dVkZ2eTnZ1Nf38/Pp9vSBDMy8vj3nvvZdq0aV7JyEMP PUR/fz+33XYbq1atorCwkHHjxvHII4/w+uuv8/nPf57y8nKeeOIJurq6uP766/n85z9PdnY2 eXl5/Ou//ivPPffckHD005/+lIaGBubOncs999zDuHHjWLFiBQ888AC7d+9m/fr1fPazn/Ve 09/fT1FREX/0R3/EnDlzaG1t5W/+5m84duwYe/bsYd68eXz3u99ly5YtNDU1sWTJEj75yU+S lZVFRkaG10/YcRz6+vqwbZuSkhL+/d//nePHj+M4DhkZGeTn5/Pwww9z9OhRqqurL8vygE2b NtHX1+cF1lgsxooVKyguLqavrw8Yub7ZDcInh+fTBeSTX3+68Hzyfga/3jRNpk2bRllZmVem BQMlQPv27aOqqupcXR4hhBAXmAToM3jjjTeAgf9IN2/eTGlpKX6/n5ycHI4fP87u3bvp7Oz0 /jMNBoN8+tOf9mpfi4uLCQaDRKNRbrvtNsrKypgzZw79/f08+eSTXlga/J97Xl4ey5Yto7Ky khkzZhCLxXjnnXd44oknOHLkCPX19bz++uskEgmmT59OVVUVM2fOpLy8HMMweOutt3j88cfZ s2cP9fX1ZGdne9tevny59xq3VVsgECAzM5OGhgZ6enpob2/3+te6C0MMPr5p06axfPlyJk2a xLx58wiFQuzdu5dt27axe/dudu3aRV5eHk8//TTJZJIZM2ZQXFxMUVHRiJMxf/e73wFQVlbG 3LlzvdHaQCAADPTdDYVC3vPdbwqqqqooKyujtraWuro6wuEwbW1tbNiwgaKiIvr7+wHo6Oig sbERTdOorq5G13WuuuoqSkpKWLBgAbFYjFtuuYXnnntuSFB/9913vf1v2rSJiRMnopQiNzeX 2tpaampq6Orq8q5NJBLhc5/7HPPnz6eqqsp77vHjx+nu7iaZTBKJRLz2coZhMGnSJKZOnUog EGDHjh3Dro2macycOZOGhgZaW1vp6+vz6qlt26azs3NMJz1eCI2NjV7tPwwE1Ly8PG+xlFPV NsOpl+IeqXvGSI+5rz3dPkYK6e6fMzIymD59Ovv37/c+EKVSKV5++WUJ0EIIcRmRAH0GnZ2d wMCks+rq6mGPt7e309HRQTQaBQa6BASDQWbMmEFJSQnt7e3AQFiKRCJUVVUxbty4IauUDe4y AAOhKRKJUFFR4Y3alpaWAgMTqXp6erxWfKFQiLy8PMaPH++1PJsyZQow0PGhra1tSPiNRCJM mjSJyZMnex0ejh07xre//W1++9vfUl9fTzKZHHI8g5dOds+lsLCQ+fPne5Pp7rjjDh599FEO Hz7Mxo0bycvLY8OGDeTn5zNv3jzy8/O9yZkn6+7uBiAzM5P8/HxKS0uJxWKnLD+IRqNMmjSJ yspKwuEwqVTK6xP8xhtveB96XP39/fT29tLS0sKxY8eIxWJkZGQwYcIE4vE4fr/fez8G79M9 rl27drFr165hx9Ha2kp3d7d3fQOBAFlZWVRVVVFRUUFTU5M34u44DrZto2matw9N0/D5fASD wVP2fFZK8ctf/pInnnjC+zZg8ERSy7Iui44bg23atImWlhbvd8MwqKysJC8vzxt9PlV4Pvkx 9/6RRqQHv2ak+842PA9+vWmaTJ8+nXfffZfm5mavI8eWLVtwHEe6cQghxGVCAvQZuCOm8+fP Z8GCBUPKCdylhAd3A4CBEB0KhYaUK2iahmEYZ92b132uuy93sQifz4dlWV53DNM0CQQCBAIB 77mJRMI7jpFGJ0OhkBfYenp6WLlyJTt27KC0tJQvfelL5Ofn8+yzz3LgwIFhX1273NDp7nPK lCksXLiQ3/zmN6xbt47e3l4OHTrE1VdfzYQJE07bV3nwiGooFBqy3VMZfA4+nw+/308kEuH6 668nPz/fu/ZKKW+/tm1j2zY+nw9d14nFYqetS3Xf+8WLFzN79mzvvVdKYds2s2fPHrKMMwy8 b5mZmUPej4/jpz/9KV//+te9D2X33Xcf1dXVvPDCC5ddcHZt376d7u5u7+9dKBTi2muv9a71 qWqbR3rsbMLzSCPWpwrIp7p1/2xZFlVVVeTk5AzpN9/a2sru3buZPXv2R78wQgghLhoSoM+g srLSC4Q33njjsBXq3NFYd7RyrLij37m5uei6zuTJk4GBUdKenp4h/5nX1NQAnHIZ4cHBbvfu 3VRXV1NSUsJ9991HZWUl+fn5vPTSS8Oeezp+v58vfOEL/Od//icHDx6ks7MTwzBYuHAh+fn5 p6x/hoFr/NZbb3HkyBFvxP5MBh9Xbm4upaWl7N+/n2g0yt13301WVtaQDyrBYJBUKkVOTg7N zc20tbUN2d7+/fuH7WP8+PHAwMInK1euHLagjmEYFBUV0dzcfMpjO91xn03ZxX/8x3/Q09PD jTfeyB133EFeXh6xWIwXXnjhkp0geCYtLS3eBxUYCNDuhNyRgvLpwrPr44TnM41yn/xYMBik vLycAwcOeB+uU6kUhw4dkgAthBCXCfk+8QzuuususrKyqKur42c/+xk5OTlMnz6diRMnYlkW ubm55OTknNOvZru6uti8ebMXjJ955hnef/99gsEgc+fOJRQKceONN1JYWEhDQwNPPfWUV4f9 3HPPsW7dOnRdZ86cOWcczU0mk5imSW9vL52dnUyePJm+vj56enoAaGtrO+v62qVLlzJz5kxa WlrYv38/ZWVlVFZWMn78+CE1zCe76667iMfjHD16lJ/85CccOHCAvr4+jh49yiuvvOKNvp/K +PHjWbp0KQCvv/461dXVlP3/7J13fBz1mf/fM1ul1apXS7ZsybZs3HBvQKjBgG3AgSO0VzgI SY7cJfcLJCSX5Jfkkgs1x+9S7rhLIQUSSkgMXIghGLAp7r1KNLi3nQAAIABJREFUtooly7Js 9bp15vfHakZbJdkgWZaf9+u19u58Z77zndlZ7Wee/XyfZ9Ikpk6dSnZ2Nh6Ph5KSEoqLi80b jxdeeIHdu3dTV1fHL3/5S55++mkgUtTedtttuFwuqqqqWLt2LTk5OeZ77/V6GTduHBkZGWf0 3judTpKSkgDMbA1GpomBKC8vx+12U1xczP79+wFirDbxuPPOO7n88su588478Xq9o94r3dvb a/6CYuB0OsnLyzOtTmcinhP5ocNfD9Q2FItIvP3l5uZG3Gj7/X6amprO/IQIgiAIoxKJQA/C ZZddxu23386vfvUr3nzzTVauXElBQQG9vb1UVFTw8MMP88UvfvFjFSaapvHss8+yY8cO3G43 FRUVnD59mrlz5zJ9+nTy8/OZMmUKt99+O//5n//Jxo0bWbVqFQ6HwyzUMWvWLJYtW0ZeXt6A NoUJEyYwdepUDh8+zC9/+Utef/11qqqqzMwO27Zt49e//jWPP/74oOPOzc3l6quvZs+ePWia xrRp0wacPGhw2WWXccstt/C73/2ODz/8kNWrV5Obm0t7ezs+n4/nn3+eiy++OOH2NpuNb33r W6aH+1vf+hbPPvssTqeTpqYmNE1jw4YNpKamcs8997Bz507q6+v57Gc/S0pKCtXV1Wa0Pvx9 XLFiBTfeeCMvvfQSL7zwArt27SI3N5fu7m7Ky8t58sknueOOO87ovbfZbCxbtox3332X8vJy Pv/5z1NWVsYzzzwTt5+lS5eyfv16jhw5wsMPP0wgEKClpYXc3FxOnz7Nk08+yaJFixKK+Nra Wt5//33mzJnDzp07mTdvXoT/frTR3d1tTv40yMjIOCNrxUAC+UyjywaJ2uKJeE3TyMjIwGaz 0dPTg6Io5vsmCIIgjA0ueAGdn5/PvHnz0HU9rm/VarXyox/9iIKCAl566SWam5tpb2/H7XZT WlpqilZj8pvNZouYLJednc306dPx+/0RZZkLCgqYNWtW3H1mZGQwb948c9JYeno6y5Yt49pr r6W4uJjCwkLsdjuPPvooGRkZvPTSSzQ2NqIoCrm5uVxxxRVceumlTJgwwbScGPmc09PTI/ZX UlLCo48+yte+9jXa29vp7u7m+uuvZ+7cufz4xz8mEAhw8OBBKisryc3N5eKLL45bbRBC9oS7 776bn/70p2Yu44EmDxrY7XYz3d7atWtpbW3l+PHjpKWlUVZWRm1tLZMmTTKPId7+J06cyLp1 6/jGN77B7t27qaqqwuFwkJaWxtSpU9m+fTsLFy7kjjvuoK6ujl//+tdm9pPrrruOqVOn8pe/ /CVi8qLD4eC///u/KS4u5pVXXqG5uZmWlhZSU1MpKytD13Vqa2tJSUmhtLTUvC6M7d1ut+n9 Ds/J/OCDD/LBBx9QWVlJfX09breb3bt3k5GRwUUXXYSu6+Zkw6985Sts27aNAwcO0NHRwfjx 47nrrrvYtGkTO3fupLGxkR07drB06VImTpyI0+mMGEN6ejopKSn4fL6YCaWjESMCbYhRRVHI zMyMKNs9FH9zogmAidrORCAP1hYMBklNTY24cQ0EAjG2IUEQBOH85YIX0DfddBOLFy9m3759 ZjaEaJxOJw899BA33HAD+/fvp6urC7vdTmZmJm63m9TUVHJycvjrX//Kpk2b8Hq9ZkaMCRMm sH79erZu3QpgCubly5eby43cy+FcddVV3HvvvTQ2NgIhn292djYzZ84kLS0NVVWx2+189atf ZcWKFRw6dIienh4cDgfp6enk5eUxdepUU7g999xzbNu2jc7OTlwuV0QmiBtuuIGJEyeamQIM z/Lll1/Onj17SEtLo729nS996UusWbOGqqoqUlNT40Y9X375ZbxeL3PmzGHSpEkDTh4MJzk5 mW9961vceOONHDx40DyH6enppKen43A4eO6559i+fTudnZ0xWTpUVWXy5Mn8/Oc/Z+vWrdTV 1aFpGikpKaSlpeFyubDb7TgcDh5++GGuuuoq9u/fj6ZpZGVlkZOTwx133MHx48cjjs3lcvHN b36Tm266ifLycjo7O7Hb7WRlZZnZPHJzc1m3bh3btm3D7/ebtpmsrCz+93//l23btuHz+cwb qIyMDP70pz+xfv16Tp06RUZGBh6Ph/Hjx/P222+zbds2VFU1hfcLL7zAW2+9RWNjI263m+zs bG6++WYOHTpER0cHLpeL5ORk/vrXv7J582Y8Ho9pmXnkkUe46qqrUFV11Ns3IOQ3j7ZwZGZm xow9kb85UXq5gaLTiQqlDCae4+3feKSlpWG1WiNuhiQCLQiCMHZQ9PPhW3WYCQaD+Hw+FEXB brcn/Dnc7/fj8XjweDxommamIHM6neaXpeEzdTgcZj+appk+3vDl4ft1OBxs2bKFpUuXUlRU xL/8y7+wevVqnE4nfr8fq9VKcnJyRBQb+lNneb1ec1xGRorwY9F13ZyEZbPZYiwVgUCA7u5u PB4PFosFl8uF1Wqlq6sLv99PcnIyLpeLQCBAIBAwBXz4WBoaGrj++uvZt28fDzzwACtWrODS Sy9NOJkxGuNYent7I7KOJCcnm7aDgY4h/Dh7enrMc2uz2UhKSjKFrbGf7u5ufD4fqqqa7b29 vaiqGnFTE+8cW61WnE6nmW1F0zQz3V/0ex9vua7reDwes2CKcX4hlHEl/FqMXjcpKQmn00kw GKS9vR2r1WoKtujrb+XKlWzcuJHPfOYzXH/99Vx++eWmB3s0snfvXr74xS/S2tqKruuoqsqt t97KQw89hM/nAwbP9TxYhNl4JPI7DxbhjifUw9sURaGtrY3vf//7NDQ0mFVN582bx29+85th PHuCIAjCSHHBR6AhlE1hKKLCEG2G0AnP6Wu8jjdZzhBoQ92vUQbYyCts7CeRbcJut2Oz2RKO y1g2kPfVarWSmppq/vwfbgEIj6LZbLaEEeXnnnuO3bt3U1JSwpQpUwadPDjQsYT/hB9+LIP5 d43jtNvtCfsYaD+GKE+0fqJzbKQujCbRckVRTCEcfn6BmGtioHWNmwLjdfS+Jk6cyNKlSykt LR3UDz8aMG5kDHRdp7W11XydqBR3vOUDiefo7aOXDyae421voCgKXV1dBAIB833RdZ3U1NQz PyGCIAjCqEQE9BmSSMh+HMyfP59nnnmGmpoasrOzzX0NJcvDxzGuRMJ7qP2uXr0at9tNT08P RUVFg04ePJNxDEcfiY53OMf1UfqMt+5g18aPfvQj054UnYJxNGJUajR+KdB13fQOJyrFHW95 IvFsMFAxlEQCOZFAj7Z8qKpKS0tLTI7w7OzsszongiAIwuhDBPQowmaz8elPf5pjx45hsVgS +oxHK5MnTyYrK4vTp0/jcrliJiwKI4/dbmfWrFmoqhpRBGi0Yvi5wwmffDdUgRzdFr79QNHl 6P1Eb58oAh4uvBVFob29PUJAW61WMjMzh34izgHGrxvnantBEITzifNHnV0gOBwOSktLmThx 4qiPFkajqioZGRlMnjyZcePGnXfjH4sYlpZEpcJHG0YE2kDXdTo7O/F4PAMK5EQ2i0QCObot vM+Bosvh2w40obCtrS3CwmGz2cjKyjrzEzJCbNy4kS996Uu89957cduffvppvvnNbybcftOm TXzpS1/ihz/84XANURAEYVQhAnqUYfhwz4doYTxaWlr45je/yRNPPBGRjkwQhoLdbjd95hD6 PPh8Pg4dOoTFYkkokKOfh7+ONzFwMIGcqC06Ap7Ig11XVxdRAMhms5GTk3NW5+R84IMPPgBC E4lramrO7WAEQRBGABHQwsfK3r17efzxx/nNb37Dzp07zcwJw82TTz7Jrbfeyu9///sY7+lI 8Morr3D77bfzve99D7/fLzcOH4Hi4uII65LH4+H99983f9EYKLqcyKKRaLvwbcL7Gii6PJh4 bmpqoq6uzrwOFUUhOTmZadOmfZTTMmqpr6/n2LFjjB8/HoAPP/zwHI9IEARh+BEBLZwV7e3t 1NTUJPxZ3ePxcPToUbq7u0dETL777rv88Y9/5C9/+Qu1tbXDJqJPnz7N8ePHY5Zv27aN559/ nr/+9a9UVFScExE/Vli4cGFEsRy/329WtxzIuzzQ/2dbKAUGLtgSbeuwWq0cPHiQjo6OiJSF EyZMMAXmWOPDDz/EYrFw3333kZyczM6dOyOi74IgCGMREdDCGdPR0cGaNWu45JJL2LhxY1yx qOs6gUBgxCrfrVq1iltuuYWioiJOnjw5LPutra3lyiuvZMWKFRw5ciRiH5dffjl33nkn06dP p76+nmAw+LHv/0Jh0aJFEWJT0zTq6+vZu3evmRc73kPTtAiLRvjygbY50/6i28LXUVWVAwcO 0Nraagpoh8PBtddee65O57Di9/vZtm0bM2fOJCsri4ULF+L1etmxY8e5HpogCMKwIlk4zoKm piazvHR4pom2tjaqqqqYMGECWVlZ5nKPx8Pu3bupqakhEAhQUlLCvHnzYnL2njhxgj179nDi xAmKi4tZunSpmdLLYO/evWZKsoMHD7Jv3z7mzZvH9OnTE3qmjWjw8ePHaWhoMMuX5+bmRuSp 3b17N6mpqZSUlET0tWfPHpKSkpgyZQqKolBZWUlTUxP19fU899xzdHV1MWvWrLgRtqNHj7Jh wwYsFgvTpk1j6tSpMZlFWltbOXLkCEeOHDErCpaVlcXkzS0vL8fn83HRRRdx+PBhDhw4wPjx 41m8eDGrVq0iNzeXpKQk89zX1tbS1NSUMAI+Y8YM8z3o6emhqqqK2tpaGhsbGTduHPPnzzf7 8vv9HDt2jNraWpxOJ6+++ipz5841S5svXLiQYDBIb28vOTk5Ecd46tQpDh06RE1NDcnJyUyd OpWpU6fG5HvevXs3LpeLyZMnU1lZyf79+wkGg0ybNo3p06efVxlZPgpJSUnMmjWLffv24ff7 UVWVtrY21q1bx+zZs/H7/cDQSnEPFj0eLLKcyO8c/tp4rqoqJ0+epLq62kxnByFf96WXXvox nqHRw86dO+nt7WXZsmUALF26lA0bNrBp0yZzmSAIwlhEBPRZ8NnPfpY33niDO++8k6eeegqX y4WqqnzlK1/h+eef57rrruPXv/41LpeLrq4uPvOZz/DWW2/R1dUFhAqofOc73+Ghhx7C6XSi KArr16/n29/+Nlu2bEHTNFNwvvjii0ybNg1VVdm3bx+XXnopGRkZ/N3f/R2/+93vOHnyJHff fTf/8R//YZb4DqelpYVbbrmFffv20dTUBIQ8mcXFxbz66qtcdNFFWCwW3n77bVatWsXEiRN5 9dVXmTRpEhaLhd27d7N8+XLy8/PZsmULDQ0NXH311bS1tQHwzDPP8Nvf/paZM2fy1ltvRYiK 999/n0ceeYTKykoAxo0bx89+9jNuuOEG08966NAhHnroITZs2EB3dzcAaWlpZk7soqIiVFXl 2LFjfPKTn6Sjo4OvfvWr/OIXv6C6upqrr76a3//+93zuc59j/fr13HXXXTz++OP09vZy4403 Ul5eHiOgFUVB0zT+7d/+jQceeICuri6zNLZRbtlisTBx4kRee+01pk6dyssvv8y9995Lb28v HR0dfOMb30BVVW677TZ++tOf8vjjj/PUU08xb948/vznP5v5r9etW8f3v/99s8w3QH5+PkuW LOGZZ54hLS0NRVHYuXMny5cvp6ioiM997nP86le/4vDhwwAUFBTwxBNPcOutt2K32z+mq3h0 s2zZMl577TWzIqHX62Xr1q1s376dWbNmRXjrE/mXz8R6Ea9tKP7n8P0pisL+/fs5fvx4RP7z qVOnMm7cuI9+UkYhH374IRkZGUyfPh2AwsJCiouLqampoaGhgYKCgnM8QkEQhOHhwghpfcw4 HA48Hg+NjY1mlAxCM+17e3tpbW1l165d+P1+nnzySdauXUtGRgarV6/m05/+NAsWLKC1tdX0 ytbW1vLFL36RvXv3snTpUu655x5KS0s5cOAAX/7yl2loaEDTNPx+P36/n+bmZn7yk5+Qk5PD ZZddhqIoHDx40BxHOCdPnqSmpoa5c+dy7733csstt5CVlUVNTQ3f+c53aGpqQtM0M3rq8/nY tm0bnZ2d6HqoLLbX68Xr9bJp0yZcLhdXXXWVWRRi+vTpLFu2jLKysohJgy0tLbzwwgtYrVau ueYaioqKOHHiBD/4wQ84fvw4gUCAU6dOccMNN/D666+TmZnJrbfeys0330xSUhJvv/02N910 E8eOHTPHp6oqPT09PPLII1itVq644gqSkpLYu3cvVqsVj8dDU1MT5eXlWK1Wrr/+eq6++mou ueQS8zFlyhR6e3uxWCwcP36cyspK6urqqKurY8GCBdx3332sWbOGtLQ0Kisr+dd//Veam5uZ OXMm1157LQ6Hg5SUFObMmcPy5cvJzc3lwIEDKIpCb28vHo+HvXv34vP5OHjwIP/wD//Apk2b GDduHHfddRef/OQn8fl8rF27lnvuuYfm5mZ0XTfLxJ86dYrvfe97BAIBrrnmGoqLi2loaOCx xx5j7969cd/jsciSJUuYMmWKKU4tFgt1dXWsXbsWXdfNQivxxC4kFsjxJgxGrxNvm8HaVFWl vr6eDRs2RNh3VFXl9ttv/1jOyWjj5MmTVFVVMXfuXHp7e+np6aGnp4d58+YBMplQEISxjUSg zwLjS9MQltFf3j6fz8xbW1FRAYRKYt96663k5+eTlJREb2+vWbL43//93ykvL2fRokV85jOf IT8/n8WLF/PVr36VPXv28O6773LTTTeZ/Xd1dbFgwQI++9nPkpOTg8vlwuVyxbVwTJs2jZdf fpnTp08DkJKSgqqqvPjii1RVVVFZWWmW6wZMIR3t4dV1ne7ublwuF48++igrVqzg1KlTXHnl lVx++eW43W7S0tLMyUOdnZ0UFxfzuc99jgkTJrBjxw4effRRGhsbqaioIDs7m9/+9rdUV1dT VFTE/fffT1lZGTk5OSxZsoR/+7d/Y+/evfzqV7/iwQcfNMfn8/koKSnh/vvvZ/z48bjdblJS UsxxGu+JEeU/cOAAbW1taJrGhg0b+MlPfoLVauWqq65i9uzZqKrKzJkzWbt2LadOnUJRFFJS UvD7/bz22mscPXqU6upq5syZw4MPPsjf/vY3HA4HN910E3PmzMHlcplRZMAUwpqm8dhjj1FT U8OsWbO47777KCwsJC8vj+eee45f/OIXvPPOO7z22mvcdttt5vg7OjoYP3489957L6WlpRw+ fJjvfve7nDp1in379jFlyhRSU1PPyxSHZ4LVauX+++/nwIED5i83mqaxa9cuDhw4wIwZM/B4 PMCZCWSDRNHl6Kj1UKPTfr+fnTt3mjdvEIpIL1iwgCuvvPLjOi3DhvG3KFHWnEAgEFMG3khd 9/bbb/P222/HbLNt2zZuvPHGs6pGKgiCMNqRv2zDzKxZs3jhhReorq7mueee46GHHmLWrFnY 7XazOtyuXbuAkPjatGkTxcXFeL1eMjMzqauro6qqio6ODvPLOzMzk5UrV1JQUMD8+fPJyMjA YrHELVyiqiqzZs3i2LFjtLa20t3dbdoA/H4/ra2tEWJ5sIwZiqKQlJRkeoetVislJSWUlJRg t9vZsGEDAHl5edx3332UlJQwZ84c8vLyeOKJJwgEAnR0dOD1ennnnXcAmDRpEqWlpcyfP5+C ggKWLFnCX/7yFzZu3MgHH3zA7bffbn4JOxwOVq1aRXFxMXPnziUvLw+r1RqR8cDAZrMxY8YM NE1j8+bNPPfcc7S1tXH11VezYsUKpkyZwoQJE7DZbMycOZOamhra2tro6ekxj8/n89HW1oau 67hcLiwWC4qi4HQ6mTVrFjk5OdhsthjrTHNzM4cOHQJCUXrDq52ZmcmECRN49913KS8vZ+PG jVx99dXme5uVlcW9995LWVkZs2fPZsKECTz++OMEg0HzvBkR2LHO0qVLueSSS3jjjTfQdR2L xUJjYyOvvvoq48aNIyUlxZzAGk8gJ8q4MZBAHmj7eDmkDe/zwYMHefPNNyNEpt1u5wtf+MJ5 YbsxirwY1qxoOjo6Ijz7gUCArVu3MmnSJK644oqY9bds2cKBAwfYs2cP8+fPH55BC4IgnENE QA8zDzzwAK+88gq7du1i3bp1bN68mcsvv5yf/vSnFBQUoCgKHR0dAOzatcsU0+E0NTVFpIOz 2WykpKQwc+ZMU0AmIhgM8j//8z/84Q9/4ODBg7S0tER8yQeDwTPOWKEoiikYFUXBZrPhdDoj ir84nU6ys7OZM2cORUVFNDc3m+IzGAyaghBCnufMzEwKCgrMKnTGhMTW1lYaGxvJz88HQjcE ycnJTJ8+ncLCQjNylmicdrudo0eP8tWvfpWqqioWL17MypUrmTJlChdddBHJyckEg0H+67/+ i+eff57Dhw9HZFCAkFgwhJLRr9G30+mMO7mvp6fHFCM5OTnk5eWRlZWF0+kkPz+fnJwcysvL OXXqFKdPnzZvYpxOJxkZGaZ47u7uNs+bYWW5kPjSl77E5s2bzXNptVpZt24dWVlZ3HXXXaiq GhEVHkqpbeP1YAI5ui0cYz1FUaivr+fFF1+ktbXV/GwpisINN9zAokWLzoubHePvyN69e7n5 5psjrmnjM7hgwQJz2e7du+np6eHyyy9n7ty5Mf2lpqZy4MABNm3aJAJaEIQxiQjoYSY9PZ2X X36Z//mf/+HVV1+loqKCtWvX0tzczB/+8AcKCgpMAXzppZcyffp0UzDpuk4wGGTmzJkxqeKs VivJycmDZmb41re+xVNPPUVmZiZLlixh4cKFbNq0iTfffHPYU8wZQj+RwDfG7vP5SE5OjhD2 hhXEYrHElHFWVRWXyzWkn4ZPnTrFl7/8ZbZv38706dNZs2YNkydPZvbs2aSnp6OqKv/n//wf nn76abKzs7n00kuZN28eGzZs4J133hk0Ip8Ii8ViHo/H4yElJcV87ff7zXNvsVjo6emJiZyn pqZecD99d3Z20tbWRmtrq/n+K4pCWVkZW7dujThHf/zjH8nPz+e6666LSCdnkCi6PJBATrRe okmKqqrS3d3Nn/70J6qrqyPeL6fTydSpU9m5c6e5vaqqOJ1O0tPTzZup0YLb7Wb58uVs2LCB X/ziF1x77bVkZmZy+vRp/vznP+NwOLjuuuvM9T/44ANcLhdz5syJ219paSm5ublUVFTQ3Nw8 qsuYC4IgnA0X1jf0x0x4NLC2ttb0O4ejKAqFhYU89NBDrFmzhieeeIKXXnqJffv28eabb5q+ aIDu7m5WrlxJYWFhhJi0Wq0UFBSYWSrOhHfffRev18snP/lJrrnmGnJzc2ltbeXNN9+MEN9G lCzazvHKK68QDAYjxEV4RG0ggWlEahNhzNBvbGyM8F729PRQX18PhCJj8foYSlSvq6uLr3/9 67z++utMmDCBNWvWMGXKFGbPnk1WVpZ5/B988AE+n48bbriBK664gpycHOrr63nnnXci9mMc j6Zpg+4/PT3dnGh5/PjxCHHX2tpKQ0MDEMpMYtwsRe/nQmH79u1mAZqWlhba29sjrger1Rpz fjweD08//TQdHR3cdttt+Hy+GGtFomwcA4nj8OeJKh7qeqhgyqlTp3j22WfZvXt3zM2Opmn8 7Gc/i3jfDetPWloa2dnZXHzxxaxcuZKSkpKP72R+BFavXo3FYuHdd99l37595vLMzEzuuece 83o+deoUR48e5YorrojxRYezZMkSXn31VTZt2sTKlSuHffyCIAgjiQjos8D4Ijl8+DBNTU3s 3buXBx54wLRfhH/Z//znP2f+/PmUlZUxc+ZM1qxZwyuvvIKu6zQ1NdHZ2cktt9zCG2+8QXl5 OX/+85/5wQ9+QFZWFl1dXVRUVDB79mySkpLOSlQZY6moqOD2228nLy+PqqoqgAhfdUZGBg6H g9bWViorKzlx4gTf/va3+cMf/hDTl9PpNP2QO3bs4J577sHv959xxHT16tX86U9/4siRI/zu d79jwYIFKIrCU089xY4dO3C73cyZMycmF/ZQ8Pv9PPbYY/zud78jMzOTVatWMX78ePLz81EU hebmZjIyMrDb7eZxHT16lE9/+tNkZmZSW1sLYKZRA8wMHIaACM8OEk1ycjJXXnkl77//Ptu2 beNvf/sbZWVl+P1+vv/971NdXU1BQQGTJk3C7XbT2dl5Rsc3FmhububHP/4xW7Zsoa6uziyS MhRUVaWrq4vnn3+elpYW7rvvPiwWi2m3iWe9SJSp40zEM4Sug/Lycl544QUqKiriXpterzfu hLzu7m5aWlqorq5mx44drF+/npUrV3L//fcP6biHE7vdzs0338z111/P6dOn6ejoID09nfz8 /IhrPDc3l5/85CeD9nfNNddwzTXXDOeQBUEQzhkioM+Cq666imeeeYaTJ0/y4IMP4vF46Orq Ii8vj4aGhogv6t/85jc8/PDDTJ06FbvdTmVlJT09PVx00UXk5eWh6zpr1qzhpZdeYt26dfz+ 979n586dZGZm0tXVRXl5Ob/97W9ZsWLFWY314osvZsuWLezatYt//ud/pru727QUtLS08Pjj jzN//nwKCwspKytj7969PP300zz//PNUV1eTl5cX4TMFcLlczJ8/n82bN7Nz507+/u//ntmz Z/Nf//VfZ2R5WLlyJZdddhlvv/02a9eu5fDhw/j9flPgL168mLKyMsaNG3fGVoq9e/fyzDPP mNkDXnvtNTODhlEY5e677+bBBx9k9uzZ7Ny5ky1btvBP//RPtLe3EwwGSUpKorW1lccee4x5 8+aRk5PD5MmTqa+v549//CNbt27l7rvv5h/+4R9i9q8oCp///Od58cUXOXz4ME8++SSvvfYa zc3NHD16lPT0dK6++momTpxITk7OWf26cD5z4MABHn30UXbu3GkK0DO1FKmqSmdnJ6+99hpN TU184QtfIC0tzRSuZyKQo5+Hvw7f3maz8d5777F27VrEWUglAAAgAElEQVROnjw54I1doms2 XNxXVlby9NNPU1tby8MPPxyRUeZc4XA4KCoqOtfDEARBGNVYvvvd7373XA/ifGPy5MmcOHGC pqYmfD4fubm5fOpTnyI1NRVN0ygsLGTp0qUUFxcTDAY5duwYjY2NNDU14Xa7Wbp0Kbfccgvj xo2jrKyMlJQUVq5cSU9PD83NzTQ3N9Pa2oqiKEyYMIGLL76Y9PR0Mz+y0+lk+fLlTJs2LWH6 OoNFixbx3nvv4ff78Xq9TJw4kTvuuIOWlha6u7vx+XzMmTOH6dOnm55NI5p82WWXcfPNN1NZ WUlGRgaf+MQnKCkpweVysXDhQt577z28Xi/t7e0kJSUxY8YMUlJS2LFjB06nk0suucSsuOf3 +1m/fj3JyclcdtllZhXH1atX097ebk6m83g8FBQUcN1117FixQomTpzItGnTsFqtpu3kkksu 4aKLLsLtdpuRsY0bN+LxeCguLmbhwoWMGzeON954g/T0dGw2G3a73YyQGwImOzub4uJirr/+ erMkudfrpbS0lDvuuINTp07R09OD3+9nzpw5TJ48mYsvvphNmzbh9Xrp7OwkNzeX0tJSmpqa aGhoID09nUsuuYRJkyaRkZHBqlWrqKuro6WlxSwxXlpayqpVq1i+fDmTJ09m0qRJ6LrO+vXr SUlJ4dJLL6WsrIykpCQCgYAp/C+55JIhveejnQ8++IDvfve7ZpaSaBRVNW0ssY/IaL9hqamt rWXnzp0kJydTWFgYYbcxSJSKLlpgR1s+DItNZ2cn69at409/+pP5+Ywa+ADj7rPlKAoQKawD gQDl5eVUVFSwePFicyKtIAiCMHpR9LOdJXWB09vbyzvvvGOWds7OziY7O9tMDZebm8u8efPM IidGPmKLxUJWVhY5OTlMmzbNLPus6zpdXV3s37+f8vJyent7zYwMRuGOzMxMOjo62Lp1KxAS x+GlxOOhaRrNzc2sX7+e1tZW03+Zm5vLvn37TMG6fPlyUlJSOHToEFu3biUYDJKZmUlOTg7p 6ekcO3aM5ORkFi5cSFpaGhDKDrJ+/XpaWlrIyMigqKiIBQsW0NPTw5YtW3A4HCxcuBC32w2E 7BDbtm1DURQWLVpk9tPR0cGuXbuoqqoyo+Pp6ekUFhZSWlpKamoqqqri8Xj48MMP8Xg8LFq0 iMzMTFNA+/1+9u3bZ2bsmDFjBr29vWzbto3u7u6IzCEGqqpSVFREWVkZra2tvPPOO7S1tZn+ 5ezsbLNQTkFBAcuWLSMlJYXq6mo+/PBDuru7ycvLo7S0lLKyMk6cOEFFRQVut5uFCxficDjQ NI3W1la2bNlCfX09Pp+PtLQ0srKyKCoqoqSkxBRMra2tbN26FYvFwqJFi8xS5u3t7eYkuoUL F5KRkXHeCuiGhgb+8R//MbZCpALW5BQceYW4Sy/ClpIKqgV00HVMzakoKt21FXSU7ybQ2d4n SPuxWCwsWbKEm266KSJLS3iGjaHkeg6f4NrV1cXu3bt5/fXXaWxsjDkmRbWQlD4ed/ESLLbk vgH3j1nXQdEVdC2Av7uZ7qaD+DobCAY8MX2tXLmS73//++dF6jtBEIQLGRHQZ4mu6+aXq9/v x+FwkJycbC43UrtBKMLk8Xjwer0EAgFsNpuZSzlc1Ol6f0U6I/OE1WqNWFfTNDNDgcPhGDQL B4QEgcfjoaenB03TSEpKwuFwEAwGaWtrw263k56ebnpIu7q6zGIkSUlJ2O12PB6PmQPamDik aRq9vb1m4RWXy2WKQa/Xa6Z6M8aYaOzGOTMqIULIj2ns2xCLuq6beZCjj904d8Fg0MyJbfSb yBqgKErEusaxhJ8jv99PV1cXNpuNtLQ0LBYLwWCQ7u5u81jcbrd5Pv1+P6qqxh23Ec02zqPD 4cBms0VYGM7kvJ1vdHd386Mf/YiXXnop4j1RrVZSL7qYohvvJq3sYvRgEF0DtDDx3PfQNVCt dlp3f0Dtn5+m50Ql0QVVjWtx8eLFLFq0iMLCQtLS0syMMEZGG2MM0ddHb28vbW1tdHZ2Ul5e zubNmzly5EjMhDldD2KxJZNReimFl34F1ZIEuo6ugWKMVw8dh3kMKBAM0lH7LicP/J7e1iqz P+N6/OEPf8iKFSsGnKAnCIIgnFtEQH9EwvPBhgum6Ahh9E/Cg3knjfU/zowM8cZqZJSIzqwR 75iM8Qyl348yPmM/5yLKeqbnCBiyoB0Nx3euCAaDvPnmm3z961+PyOqiWCzkXrmKkju+gGJz ovv9pniOK6B10INgsTvoOV7FsT/+mI6je9B8XhRL5JQOY0JhQUEBM2bMYNq0aWRlZZmWnnA/ vFHB0uv1Ul1dzaFDhzhy5IhZ9j3yPdbQgxq2lCxyZqwid/7fg2YMDlMwhyLP/ceghAlqVXXg 6TjGiW1P0NG4G+MmQFVVZsyYwSOPPMKkSZOG900RBEEQzhoR0IIgDDsNDQ187WtfY/fu3f0R X10je9lVTP3Cv6Drihm9HUg8G1FotJB1ItDRSv1bz9F+YDO9p+pA12OEtKZp5sPhcOB2u0lO TiYlJQWbzUZPTw9dXV309PSYvxKE5/EORw/6sTjduHLLyLroetJKrgFN6xfPev/Y44rnMIGt YMXbUU3Nh9/G03EcCN1QqarKV77yFe64444BCwUJgiAI5w4R0IIgDCs+n49nn32Wp556qn8C XyBA2pxFTPvH/4slKQU03YzO6kHiCucIS4Rhi1BVFNWG52QtbQc30bRjHV3HDqEoaoyQNojO BQ39vwjE/1VARw8GUCx20iYuInvmTbgK5qLaksHvDQl6PfZhWDmibwT6LR06imKlp2kvVR98 naDfY44lPT2dX/7yl5SVlX2UUy8IgiAME5LGThCEYaWrq4tXX301QrCqDgdFN/wdlmQ3BLVY YZxAPCtGBNpYFtDQdS/OnEJyl3+K1NL5NO38Gx3lW+g5WYkeCIDFEpG9Y2j2GR1dC6JrGjZX Bu7C2aSVXEZK4XzsKfloAT+6zxsrmsPGGFc8mw8ddAVdC+JMn05m0VWcqlyLoob8+B0dHezY sYOSkhJsNtvH8j4IgiAIHx8ioAVBGFaOHDlCZWVl/zyAgJ/sZVeSUjIdRdfRwsRzTLQ5Wpgm aNd8AUAhKXcS4z5xNznzb8DX1khn5U7aj26n+0QFetAPfUI6do4CER3bXVmkFM7CXbyY5Jwp WJOysDgzURUFLY5wPhvxbDxXFSuZxStprd9AwNcJhNLvvfXWW1x33XVkZGQM0zsjCIIgnC0i oIURwx8Msq/qBDuP1rFyySzyM9znekjCMOP3+3njjTci7RJWG1mLrsSa5EYLBM9MPGux7f2W CR1dD6BY7djTC7CnFZCcP53shWsIdLXhaTqGv7MVX/spAt0tBLpb0QI+LM5UbK50bMlZWJKy cKYX4XDno9hcWKxOFNWGFtRB00JifyDxHEfoxz76xTN6KMe0NakAd858WurWo6ih0uXbt2/n 5MmTIqAFQRBGISKghWGnuaObn6zdwPIZJfz9k88BkOZK4pZLL76gMlFciAQCATZv3twffQ4G cZfNIrlgfMSkuo8qnqOFtKKHPNWKxYY1yY7VmYYjY0Jowp/WN1nRWEcHUEDruxY1te81Ia90 IDjw/vTQ9D89zvgTR5/7/gfQNaw2N6l5S2mpe8s8d7qus2/fPsrKys7b1IWCIAhjFfmrLAwr uq6T7nKy5fAxxmX0lyneXn4sIp2ZMDZpbW2ltra2f0EwQFrZHOwZeehBbUDBGU88JxbN/c9j IsCajh7U+4SyClhQFAuKYkVVrCiKFXRLqE1X+/bXN8lwMLHeJ57pu4yVAdePJ56N5yoO1wQc roK+gw19dg4dOmTmrRYEQRBGDyKghWHDqPoWCASYVpTN0eONjM8OVR/ceaQOv9+fsMiJMDY4 ePBg5E2SasGZPx5rkiuUOznBpMFE4jleYRU9qj3eOvFsFXqc7eMK8CGIZ10HJU7qvfi+5yjx rIMe1LFYUnEkF/YNKMThw4flMyIIgjAKEQEtDCuapuH3+5lSkMWeyjqmFoT8nEdONNHR3RNR VlkYe9TU1PS/0HUsyS7saVmhVHVxxO+Ziud4Eeuhiud40eJ4AvzjFc+6eS7MZZqOoulYrG6c rsJ+u4uuU1NTIwJaEARhFCICWhhWdF0nEAgwKSeVw8dPU5IdsnEEghq7jtSJgB7jtLa2ms91 XcPiTO7L+6z1l+s2hHT4/0EgGNtO1HqJnkdvT5yHKcAHWCfuQ+/PtoHWJ57jrtsXYdeUsGi7 ErtMA13TUS0ubI489LAIdEdHh1nGXRAEQRg9iIAWRoTJBZkcO91OSW6quWx3ZT3BYPAcjkoY btra2vpf6DqK1YZqtaP3icd4EwYHijpHL4vOemHYMgbaNlE0eqiR5+gIdvxCKlFR5wjbRtgy re81OqpiQ7W4Ys5hZ2fnR30bBEEQhI8ZEdDCsKIoCqqqkuSwk5fmwqKq2C2hy25vTYNEoMc4 7e3t/S90UG02VJsDPTiwEE4kgM1HnHLZiWwZZ2PxGMi2EZ7v+czFsxLVDtC3DAuqNSnmHHZ0 dHzEd0EQBEH4uBEBLQwrqqpisViwWCxMLsikrqWLSTmhKPTButMEAgER0WOYiAwSSugfXVNi osxDTVUX1ycd/jpRWe14Av0sxLNh3xh4/YHEc1S72RbqVzHWD0M80IIgCKMPEdDCsGHkeDZE 9NRxWRxr6mRKfjoATR09HD/dKuL5AmSgCYODiWf0jy6eo/sYqng295kwrZ4+iHjWI/8nSlQL giAI5wUioIVhxbBwWK1WyopyqD7VztQ+AQ2wq7JeItAXGgOI54FEbMRzovo4Q/Ec7b8eqnhW Eto2CBPKA4lnox1CxVqilsnHQBAE4bxABLQwrBgCWlVVinMz6PYFGJfZX1BlT9UJKahyoREd AT6TSYPhmTvOVDyHZ+A4G/Hcd4mahVPiimcGEc9EiWejrW+xfAwEQRDOC0RAC8OOoiimD7ok L52OXj9ZKU4A9tWcNAW0iOgLg4gsGWcqnqPF8RlGns86z/OA20cJZYxlidrDxXP/QxGrsyAI wnmDCGhh2AkX0GXjsjnW3MnkvFBFwooTzfR6vSKeLxT6RLOuMWie50S5nunb1ijGkuhxRrmd zyDPszJonme9bxlR7XpYe+w+zZuB2HmEgiAIwihDBLQwrCiKEuGDnlqYTc3pDqb0CWh/UGN/ dYNkGriQCLctDCFCHBMBHsAvnTDCfAa2jXj7jJ60OLRUdZHHakaeo8ffd04Mi4ggCIIw+hEB LQw7hoi2WCxMK8rhWFMnZeMyzfbdVSdkIuGFxiBCOULQRnmeB7RdDCKMh2LbSCiewyPPgxZJ gfgTBqP223cuzPR18hEQBEE4LxABLYwIRiq7VFcSGSlOnDYLFjUkGvZWN8hEwguJOBHkuHma 9f51zzrbRpRQHYrnOVHkuf8xkHgOT0s3dPGsSxYOQRCE8woR0MKIEG7jmFKQxYm2HrOgyv7a RimocoERLZSHUzwPKXJN2H7j9WnuOzzKHCueFVQULP1Cmmg7ByKeBUEQxgAioIVhJ9wHbRRU qWnqZEpeKB90Y1s3jS0dIp4vBPqE4kBR3vgWCgVFtaBarPQXHxm6eB5QfBPbV2LxHB5Zpv+5 roKm4es5ia/7BHrQB6hDFs9KRIo7QRAEYbQjAloYEcIF9LSiHKpPdzAlP81s31V5XCLQFwjG RL9E4leJaQ9ltPCcrqWr7iCazwsoQxLPZjaOIYrn8P2HZ8iIm8c5LPKsB/20N7xPzfb/S9W2 b9By/C/oAQ+KrkZuZ+4jgXiWy18QBOG8wHquByBcGIQL6En5mbR1eynus3AA7KlqYNUy8UFf EPSJ00R5miOEtAYEA7Qd2czJD5/D19VM3rybyL54NRabG13XBhTPQ7VtKHH23/8IF8860eJZ wYKvp576Az/D010PKPjLf02y+yKS06aDFogQx3HFM7pk4RAEQTiPkAi0MGIYAtpqtTIpN51u b4C0ZDsAe2tkIuEFQ5w8zfFyNuvBkMD0d7VQ+8ZTdNTuxdvWQN2GX9BZs5vQ5LzY7T5qnueI bBsJ8zgrYevoBHxt9HYdR1HtKKoNj+cU3u5j6EEtQsgrmoKu6SiagqKFCXFN6fdfD/sbIAiC IHxUREALI0aED7owi9rmbtMHXX6iGX8ggFQkHOPEifTG9UEbEwhR0AI+vO2nUK12FNVK0NeL t70BPRCMsUckzAMdtd+B8jz3P8KzbUB/5DkyAh0ar6GSQyiKgh4MgJHfPMy2ER51Dh+/RKAF QRDOH0RACyNCeC5oq9XK1HHZVJ9uZ3JeyMbh8QU4dOykFFS5UEgkXvsiz2bU1ohGh91UKSgQ 9IfEaTzbRoR3OWpfDFU868QXz+Ft/csUY52IY+zP7RybbSNSPIsHWhAE4fxCBLQwYoSL6Onj c6k61c7U/AyzfVdlvUwkvAAwo8vxxHMi33KUONV1NWHau8E8z0MTz1F5nAfM8wwJha8ex/Mc TzwTJuwFQRCEUY8IaGFEMSwcGe5kUpx20pKdqIoUVLmgCLMsxLNtDCUiqxh6OkwID3XC4MDi GUyfc1zxHE9cJz7O+Nk24mTd0GPi14IgCMIoRgS0MKKE+6CnFGTS0N7D+KwUAPYdazQFtIjo sU20V1kPEkfIEikyIzqgz9oxhDzQ9D8fVDybkwUhvniG+JHpRMcZJZ7RiTmu6BsAQRAEYdQj AloYMWILqmRzrLmTKXmhfNDHmzto7ugSH/RYJ1wwGp7nBOJ3QAEdJYQVYrePFs8DpqszsmwM KJ4HqDCY8FjjTxqMORcingVBEM4bREALI0p4Se+yohxqTncwJT/dbN91VAqqjHnCo8FDKM8d 71IIjyabQlqL2p446ySKcJviWWdg8RyvPfFxDlU8R0TFBUEQhFGPCGhhRAmPQJcWZNLY3sOk qIIqIqDHOBF5niFRvma9L0cz0T9I9M3Di143Xp7n8D4GzvXMAHmelQHbzTFGm5h1+oW2uX7f +MLzT4eJZ0WP7UYQBEEYfYiAFkYcQ0A77HaKc9Lwa+ByhIpi7jt2UiYSjnUGiAjHeKMHszaY EeTI9YcUdTYmBMZ4nhNEoOO0hyYJDjS22AmDEVHn8PMRmUpaEARBGMWIgBZGnIiJhOOyqGvu MguqHKw9RUAKqox9EojnhNk0ogj3UEeIZz6qeIaBxXN/u5lhg/hjNJdH2TbiiWczQi4IgiCc F4iAFkaU6ImEZYXZVJ/uYEp+aCJht9dPeV2jTCQcw0SI2kQ5oQcQzxiLtf4Xho41hPWQxLPZ /2B5nmPbw8WzaUOJN8go8Rzhcw4/BxEHJgiCIIx2REALI06kgM6h+nRkQZXdVSfEBz1WMaKt QxXPiUR0WPQ5XDwPqa/wEt1DyvMc2R4pnpWQ13qg4+37Xwk7logIurGeXO6CIAjnDdZzPQDh wsQQ0HkZblRVJdPtNNv2VstEwjHPUMUzxBWWSlRTeB8Di+dwgdxfanvwPM/9zyPFs44SNp6I McYRzzE2Ffqfm5YOQRAEYdQjEWjhnGCU9A7lg87kdIeHwgwXAPtqTooPeiwzRPE8lDzQ0XaN gSoSxohnXY9MXxcenU4gnpU+0W2I5+jIcrxxRuSejho78cYtCIIgjHpEQAsjTrQPekpBFsea u8x80DWn22nv6hEf9FjDCPjGEb7xxHOM8IxC12LF89B8z4kizwPngTasG5HiOayv6PHFOYZ4 0WdFj7u5IAiCMIoRAS2cE8ILqkwryqGmqcOsSKjrOnvEBz020YmfuznBa3NZdDdGFHvIeZ6V /ue6HtU+WJ5npc9r3S+eFU0JLQ/vKwozF3WfSDbzRRuCP+wGIKJNEARBGPWIgBbOCeER6Mnj sjnR2k1pn4AGRECPZeJEimMqD0Y/zqCv+FFnPSzyHJa+bkh5nkMDCBfPofXD+h+AeLaSRJ5o KaIiCIJwfiACWjhnGD7oJIedcRkpKIqK02YBYG9NgxRUGcOEi8ZBU9jFuwQSimbjEUc8G57n AcUzJBLPkeMI7z+B8NXjiGcSiGf6CizK5S4IgnBeIAJaOGeoqmraOKYUZHKsuYvS3FAU+kDd aZlIOFYxUs8NJp4Hi8qeceQZInzQQ87zrPSNVe8X0tEVBoci8sOWxYjnwSLtgiAIwqhCBLRw TlCUkKgJL6hS09RhTiRs7/ZQ1dAkEwnHKmHe4IHTziWIypqCN94jjniOyLZxZnmeY8QzUfsj 7P+YcUauo4Qdd7h4NidCnsk5FARBEM4ZIqCFc0ZEQZWiHKpP9U8kBCmoMiY5g8jzQNFdXcec SBgbfTb+D0v7cZZ5nmMjz3rEREDjmBJeotHimQTiOXp9QRAEYVQjAlo4Z4QL6HFZaQQ0nXHp LrNdJhKOTc5YPGugRIVmFZQ4k/OiosxEL6M/Oj2EPM/xxHNMbmojchw3St7/v5mqLoF4ljzQ giAI5xcioIVzSng6u8n5GTR1e8lPSwZg/7FGcyKhiOixw1DFs94nngcUlTHimTjiGSKE8hDy PCcSz4rZR/++44rnsPEpYZ5vY90BxbP4OARBEEY9IqCFc4ZRUMWoSBjyQXcyuc/GUXmyla5e j/igxxjhuZvjPUxrRvjzmE6it4uX5zls2RDzPKMTKpKiYS4P9deX99nsIyz/dAIRbeR+1unL +Rx+XHpkbmhFB5lIKAiCcP5gPdcDEEYXtd0ja5nQNA2fT6enFzIyM3jv8HEmZqUCDQQ1jbcO 1rFkdgo2WyhSLZxfpJfOpNQbet90LYjdnUteQQrWZCu6Fh4d7tsg/LkGoOBPczN58RUoaijF oab5ySmdSNo4G+gWzHB1RLaNvieGYCbUV8JJhMZ2KP1FUYw+tPASikaWjv7NVBR6e7Pwuq9E VW3mGAtyC0lx2UIB5fB7wKjjNdLXqYqKrWcctF+BqtjM1VtVF8e6gmdy2gXhgkNRFCa45DtC GDlEQAsmuq6PuOfYnLClKEzKz+JESweXTR9nth+sqmfB9MlYLJYRG5Pw8RH3WtJ1dF0DTYsR zjph1fl00FHDBHBkH5qmo5g58ejvwHhoYcv6tgHM/hQ9cnzG64g8zcZ25mqh6HT4Sx2VSIUc 1ojWb9UgKlpt6PbwzuL10ve5FAQhMYqioOuKmeFJEIYbEdAC0P8lPdKeY13XzX3arBay3cmo ioLNouIPahyuPYnP50Pts3kI5xfh15KODpqOFgygBgLoWl9UNVw8E9LV/f+r6MFAaFu9X3Hq ehBdC6DrKv1KNM7DHEjYa6P/qCiwFu1pNoRylOA1tLJiLlPRtZA/Qw8T85qmoWuBiOODPlsK YYVTjP0rFjQtGDq+sMEHAgECgcBgp1oQLlgMO6CmhX6pFBEtjAQioAVT5ASDQQKBAMFg0Fw+ EvsOBoMEggGCmkZhVir1zZ0UZqRQ09TB0RNN9Pb2gKJgtVpRFIXaxiZefX83KUlO1nxiPqmu pGEfp3B2RFST1EHTNbRAAC3gjxDQRrQ3vMBKaJmCFgz0CdA+Ia6DHgyiBXxAHAuH4VsGIi0a /XmetbAxKfS97nuuh1k1wm0bEB0dp0/1K2haoG83/WPUtADBoL9/Xfp9zhGCvW99RVFCNwVG B334/X58Pt9HfSsEYUxiiGWLxUIw2B+BFhEtDDcioAUgMgI90lHoYDCIpoX2V5STSkVtI0WZ LmqaOmjr6uXE6RaKx9nRdZ3uXi9f+fHzdPZ4ADhQVc8PP79G/liOUsKvIb1PFWtaAE0LgHmj 1i8idSKzVuiofZFm3Uxlp6Oj6VqfANf7Nww1xniMo5eHOyYUvd/pEZNqLk4E22gPd40oSpwx 6nooKq0FzEh39A1CeNfooKKi6cGIfgDzxlYQhFiM6DOApln6Pj/yfSAMPyKgBRNDNJ8Lz6Wi KKgWC8W5mbyzu5KFJdlmW3ntSQrzskFR2LCr3BTPAPurjuPz+bBarTLJcBQSaeHot3Gg6aFs F8Z6/SuYFofQwgSe/L4+IpStES3WDDOIsVyJVaw6YESbzed9jboSs64pfonNlqHrWmT//YM0 I91x80BHvTbD7mHR9uhzKAhCJLquo6qqfE6EEUcEtBCDKXiG+Y/RjvJjeH1+FkwrRiH083le hpteX5Acd7K53pH603xibijC9+H+iog+CrJS8fu88rPdeUG/bcLw+RoiMsIWYa7TZ6kwvcjh gtvwCYdFoPXwdeIsCxevhkjVwyYKho0tWugmzNlMaIzmuGI+M3rENn2yPlY8h5+f6B5EGAhC QkKTB+XzIYw8IqCFEUfXdf7jpbdYv+MQAFPG5/Kdz6zC2jdRsDDbTZc3SFqSnfZeH5X1TQQC AXq7PeyvPhnR16wJuXi9XqxWm0wyPF8wxKQhnIkqaR2V+znhLVG0VSOOXSOmre91f4aNsHWi to2wlSTaj/FfvO9vvT/3sxK2aUy+58H6EQRBEEYd8pu3MKLouk6P18vbOw+by47UneKRZ1/H Hwyiqirjs9No7OihKDMFgNqmdnp6e9lysJJglLVkRmEGAX8g5ImVKMT5Q5SI1RMI1AHf0gEE cqK28El8QxHP5jbx+o3qM+74wsQzRO033hgEQRCE8wIR0MKIYWTcUHWN9BRnRNuBmgb+3x/f QQcm5KZzsq2HokwXAIGgRuXxU2wrr43YJiPZTkFGaB0lcZxSGIUYNgZdTyyewx0acTuI3iZR H30YFpGPUzwPJnzPRDwPWBJcEARBGFWIgBZGFF3T8Hm93HX5HCxqpOjdUVHLr97YSnFuOg1t 3UzIdptth2tPcvBYY8T60wrSsVitWK2WiJnYwijGiDwnsllELTfsHYn6OlPxHFcIR+1zQPEc vf8BiEhfN9C+z6BPQRAEYXQgAloYMYzsHgG/n0nZKdw0b2LMOu/vr+Yv2ypISbLhsFmwKKFL dHfVSXzBSPvGzOJs7A4HVqsNRTJwnDeEe4uB+NzgFdsAACAASURBVJ7l2KexxBPP0X0RKZ6V 6G3jCHZjm4j2eNvFG3schiSeRTgLgiCcVyi6GEcveAxh6/P5qGr3EQgEhmXmv6Zp+H0+urs6 aW46TWtzM5sqTvDW4caYdUvz0lkwKYcPKk5wvKUbu1XFF+gX0G6HlW9+ailZObmkpadjdzhl EqEgCMIFhvHro9VqpSTNjt1ul2qEwoggWTiEEcPI9Wyz2XEmJeFMSmLBpGx6vH4+rG6JWLey sQ2LAoXpLo63dEeIZ4CygnRsduOPpUX+WAqCIAiCMGLI797CiKEoCqqqYnPYcblSSHGnkuxy cVlZARePT4tZv+JkW0ID7MwJ2TgcTmw2O6pFBLQgCIIgCCOHRKCFEUVVVaxWG0nJyQSDGrqu oetw7UWFeHxBDjd2Ray/vboppo8ku5Wp47JC/mebVX6uEwRBEARhRBEBLYwoiqKEvMp2B66U vnpyfX7rlbOK8ASOUdPca64f1GIj0GV5qTicTrFvCIIgCIJwThALhzDiGCLaZnfgcqWQmpaO OzUVV4qLm+eMpyDVOeD2Mwz7hl3sG4IgCIIgjDwioIVzgiGi7Q4HyX0iOjUtDbc7hU/NG0+W yx53O7tFZVphFja7HatV7BuCIAiCIIw8IqCFc4aqqlgsFhwOB64UN+60dNypaWSkpnDLvCLc jliH0cTsFJKTkrDb7VgsVhHPgiAIgiCMOCKghXOKqqpYrFacTicpKe5QFDo1jZx0N7fOL8Jp i7xE507MwW7YNyT6LAiCIAjCOUAEtHDOMUS0w+kkJTWV1LQ0UlLTKMhM5da5hTgsocvUalGZ Pj4bu92O1WoT/7MgCIIgCOcEEdDCqEBVVaw2Gw5HSESnpaeT4k5lfE46N84Zh1VVKc1xk5Kc jM3uwGIV8SxcAGgagap3QNMGX1cQBEEYMSSNnTBqUBQFq82Gk/7y4gBTFIWbUFCsduwOJ3aH HYukrxPGOLqu49/3PIHqjQQa9mBfeD+q3XWuhyUIgiAgAloYRRiVCkMiOgld10EPLZ/jTMLh DJX/tlptKOJ/FsYwuq4T7G0jeHIfANrpw/g2PIJt8QOo7gK59gVBEM4xYuEQRhVmuW+bnaTk ZNypqaRlZJCanoHLnYLT6TTT1wnCWETXdTR/L/49fyA457Po6cUAaN1NeN97nMDJfaGbS0EQ BOGcISpEGHWYkWirjSSXC3dqGmnpoRR3DqdTJg8KYxpd19EUG1pGKRx8ns7CT+LLuTjU6Pfg 3/qf+I++JSJaEAThHCIWDmFUYhRaURQFVVHRnCE/tMViDZUCF4QxiCGKNU3Dn78YHykkVb1K Z94y7PYsUk68DbpO4MDL6B3Hsc25E9Uav+iQIAiCMHxIBFoYtYR7om02Ozab3RTVEoEeg+ga gZqNoF/YGSd0XTcfgdRJtI1fhevUNoKBAG2T/g7dGip1H6zbgu+Df0frbZNotCAIwggjAloY 1Rgi2qhaKMVTxia634N383/i2/17fPtevOAFofELjMViQUnJpaX4Juyek1hbD9FccjtaUhYA WmsN3o2PEWytueDPmSAIwkgiAlo4LxDRPDbRdR2tuxnve48TbNwPQLBhN8GeVnRfzzke3chj /LoSmgNgxeFw4HA4sCen0TZhFZo1iZQT79BcuBp/WikAem8rvg/+nUD9dhHRgiAII4QIaEEQ zgm6rhNsqcK78VG0jhOhZalFBOd8Fv++F9A07YIUhEb02WazYbfbcTqdfULaSU/BJ+hJm05a /V9py1qMJ3dhaKOgH//2X+I/9NoFec4EQRBGGhHQgiCMOLquE6jfju/Dp9C9nQD4M6fTOWEl HHoJLW0SmsVxQYpBIwptiGiHw4HT6TQf/uzZtBdcSVrDenpsuXQW3wB9E2sDFa/j3fo0ms9z jo9CEARhbCMCWhCEEUXXdfwVf8W//ZcQDADQm7eYjvQ5JFX+mZ68pfgLlpgR6AtdRIdbOQwx TVoxreNvJLltH3pPMy2TPo1uC1Up1Br24H3/cbSupgvy3AmCIIwEIqAFQRgxtIAP345fETj0 amiBqtIx4QY81gzcDe/SXrQCf9qUiEwUFyrhfmiLxRIhoh0OB5aUbFon3ozq78J5egfNk24j mJwHgN5xAu97jxI8XXFBn0NBEIThQgS0IAjDjq7raJ5OfB/+P4LHt4UW2pJonXQb9LaQ1H6Y lvE3gbvQrDQp6QqJENAWi8X0RBu+aLszhc7x1xFw5uCuf5OWcdfjy5wOgO7twrf5PwjUvCci WhAE4WNGCqkIgjCs6LqO1tmAb/PP0HuaAdCSMmkpWk3S6S2AQuuE1dicKdjtdux2OzabTUR0 GIaQNs5FeHRaURR685fhb8kkvf512vM+QbIjk+SGD0DT8O/5PXpnA9YZn0K1yJ98QRCEjwP5 ayoIwrCh6zqBxoP4d/wc/KGJbf7UibTmXUFqw3p8SYV051+C3W4PRVT7BPT/Z+9Ng+Q4zzvP X7551NV19ImjgQYgkBRvWbxESqYk2pItW7IkyyPbGw47whPhY7wRE7EzsR/8YWL2y+yOdj0x sx/mcIQV9nhs7856ZI00pkSKNEWRFEmABEmQBEHiPvq+66483/1QnYXsQjUAEugD6OcXkUB1 VWVVVlXWm/968v8+f8uyOqE5Qpv4vUhW6OMe6UopvMG7WHKKlCafoV66h+DAr1K48PcQ+gRn fkxUncR5+Pcw7Jy8r4IgCNeJoeXc3rZHa00URXiex5myRxAE295/Klw/Wmv8sz8hePe/QtTe l1rDP0O1cC/FyWepDXwSf+j+TqeJXuJZhN7lxN/NKIoIwxDf9/E8D8/zcF2XsFmmOPE0gV3E H7iX0sXvodwyAKpvGPuRf4LK75L3VrgliMcJy7L4WLE9hkjglrARiIAWREALN5woCvHf/Q7h mefaVxhQ2/15XLNEYe4VyjufICzsuxQUsmLbEP/ztZEU0VEUdUS067p4nofvueQnf4zpl6nt +hwDU89gVi+2V7bT2A/8Y6yd98l7LNz0iIAWNgsR0IIIaOGGobVG+y28I39GNHOsfaXpUB77 Crq5SKZ8guW9v4TKjXQqzvGSjGqXg9+1kaxEB0HQqUTHS2ruCNnlY1R2f5FC5W1Sc0fbKxpg 3f1r2Ld9Qd5r4aZGBLSwWYgHWhCEG4LWGt1YxD3079EryYKRk2d57Os4i8cwgwpL+7+BlSlc Jp6TXl7h2klOJOyeWGgYBt7IQ4SpAUqTP6Iy/Bj+6BB9k8+B1gTHvoOujGN/4rdQlrPZL0UQ BOGmQgS0IAjXTRzL7R/+T51kwTC3i8XdX6Jv5iVCq4/lsa/hpNId0ZxKpTp+Z6kYfXTi9y3p G08Kab//NhadAqXxp2nlP8bygV+neOF7GEGL8OIhdG0G55E/xEgX5TMQBEG4RsTCIYiFQ7gu 4lhu/83/3EkW9PrvpDz4KQoTz9AsfZzW8MOrhHPsdxbxfOPo9kV32zmCZpXi5I8IDQd35CH6 L34P1VwEwMj0Yz/8B5j9++SzEG4qxMIhbBYioAUR0MJHRmuN/8EPCN7/H53rmjs+RT27n8L0 81SGHiMc+PhlberiYBDxO9944gj07g4d8ZKbfgGnOUN11xOUZl/ALp9ur2ja2J/8HazRh+Qz EW4aREALm4VYOARB+EhEgYf/1n+5lCxomlRGv0QQhhSmf0J59y+g86OkEuJZOm2sP0qpVT9+ u33Rzd2fJ5h/m+L4D1ne+QT51ADp2dcg9PFf/za6Mol911flsxEEQbgCIqAFQfhQaK3RbhXv 8H8iWjzTvtLOsDT2dczKObLNSRb3fh0z1086UXVOThYU8by+dIvm7uAVd+h+yk6J4vRz1AYe wt/3ZfLjT0EYEpz4YTt05ZO/i3LSm/1SBEEQtiRi4RDEwiFcM1prwsoU/qG1YrmhsvuLnVju ZOU5tmxIp42Nozt0pdvOEdUXKU7+kMXdXyYdVeg//98x/DoARmE3qUf+CCM3KD92hC2LWDiE zUIEtCACWrgm2rHcx/CP/NlHiuWWg9rm0Gtyoe/7ndCVwG0wfPLP8bK7qI88Rv/EDzDrMwAY qT7sh34fc+h2+eyELYkIaGGzEAEtiIAWrsqHieVOCmiJ5d46XCl0xfd9MtOvkKqeobL7CxQX D+EsHm+vqBT2fb+Jtf9x+QyFLYcIaGGzEA+0IAhXpFcsd333E7TMIqXJZy6L5Y5FtEwW3Fr0 Cl1J+qJbuz6NnxqgNPFDyjs+RzY1QHbqpxBF+Ef/Bl2dxLr3myhlbvZLEQRB2HREQAuC0JOr xXL3LR5mce9XULkR0hLLfVPQK3QlWa3zBu5kySlSnPgRjdI9BAd+lcKFv4fQJzjzPFF1Cufh 38Owc/K5CoKwrRELhyAWDuEyesZypwos7/06zuK7mEGF8uiXJJb7JqV7cmGyX7TruoTNMsXJ pwmsIv7AvZQufg/llgFQfcPYj/wRKr9TRLSw6YiFQ9gs5AgnCMIq4lhu94V/3RHPYW4XC2O/ Rmb2FUCzPPY17GyxY9tIp9OrAlJEPG9tktYN0zQ7vvV4sbIllse+DkBm9qcsjH2DML8XgKg2 h/vitwhm3pEf2YIgbFukAi1IBVrocNVY7uIdtEYekVjuW4grTS70PI/U3Btkl9+lsuuLFKpv k5o72l7RAOvub2Df9kX5zIVNQyrQwmYhHmhBEIC1YrkfpZ7dR3HiqU4sd8qRWO5biV6TC5PB K+7Ig4SpAYpTP6I2/Bj+6BB9k8+B1gTH/g5dmcD+xG+hLGezX4ogCMKGIQJaEASJ5d7m9Jpc mAy98fsPsuTkKY0/TSt/gOUD36R44fsYQYvw4iF0bQbnkT/ESBdlPxAEYVsgFg5BLBzbmKvF cjvNSZZ3/xJmrn9V1VliuW9NeoWuJJegVaM4+SNCLNyRh+m/+D1UcxEAI9OP/fAfYPbvk/1B 2DDEwiFsFiKgBRHQ25R2LPck/qH/kIjlHmRxz690Yrmro7+AlcpJLPc2I4qi9v7R1aEjXnLT L+I0J6nu+nlKsy9gl0+3VzRt7E/+DtboQyJghA1BBLSwWYiFQxC2IRLLLVwJpdSqH9DdPunm 7s8RzL9DcfwHLO98gnxqgPTsaxD6+K9/G12ZxL7rq7KPCIJwyyICWhC2GVeK5S6N/7ATy52S WO5tTbdoTk4sVErhDt1HOVWiOPUP1AYexB/7MvmJpyAMCU78kKg6ifPA76Ls9Ga/FEEQhBuO WDgEsXBsI9qx3P+N8MyP21cYUNv9BK5ZpDD3isRyC5fRHbrSbeeI6osUJ5/Cy+wiKH6M/vPf w/DrABiF3aQe+SOM3KDsN8K6IBYOYbMQAS2IgN4GrBXLvTz2FWgukimfYHnvL6FyI5clC0os t3C1yYW+2yA/8Sym9qnv+DT94z/AbMwAYKT6sB/6fcyh22X/EW44IqCFzUIEtCAC+hZHYrmF G0Wv0BXXdTtCOjt7iHT1NJXdX6C4cBhn6Xh7RaWw7/tNrP2Pi7ARbigioIXNQjzQgnALE8dy +4f/E9qtAu1Y7sXdX6Jv5iVCq4/lsa/hpNKr0gVlsqDQi6QXOv47eV1r52MEqQFKE09R3vFZ sukBslM/hSjCP/o36Ook1r3fRClzk1+JIAjC9SECWhBuUa4Yyz3+dCeWOyWx3MKHIN4nkr74 5JkKb+BOlpwixYkf0SjdTbD/6xQuPgmhT3DmeaLqFM7Dv4dh52T/EgThpkUsHIJYOG5B1o7l 3k9h+sedWO7uNnUSyy1cK92TC5P9ol3XJWiWKU0+TWAV8QfuoXTx+yi3DIDqG8Z+5I9Q+Z2y nwnXhVg4hM1CBLQgAvoWIwo8/Df/knDi9fYViVjuvsW3KO/+Ijo/elk4inTaED4K8cTCKIo6 Ijr2RfueS9/kj7GCMrUdn2Vg+lnM6sX2inYa+8F/jLXjPtnfhI+MCGhhsxABLYiAvkXoHcud ZXHv17Cq7Vju8ugvobISyy3cWHpNLkwuqbk3yC6/S2XXFylU3iY1f7S9ogHW3d/Avu2Lst8J HwkR0MJmIR5oQbgFuJZY7uV9X5dYbmFd6A5d6f7bG3mQMDVAcepH1IYfxR8dom/yOdCa4Njf oSsT2J/4LZTlbPZLEQRBuCZEQAvCTc61xnJ3V51lsqBwI4n3oaSHPimk/f6DLDl5ShNP4/Yd YPnANyle+D5G0CK8eAhdm8F55A8x0kXZHwVB2PKIhUMQC8dNzJViuYuTz3ZiuW3bXiWgJZZb WC+uFLriui6hW6cw8SMiw6I1/CAD4/8D1VwEwMj0Yz/8B5j9+2S/FK4JsXAIm4UIaEEE9E1K FIX47/wt4dnn21dcJZZbJgsKG0kURW1rUVeHjnjJTb+I05ikuuvnKc39BLu84ts3bexP/g7W 6EOyfwpXRQS0sFmIhUMQbjKuFsvdt3iYxb1fQeVGSEsst7BJKKVW/Qjv9kU3dn2WYOEYxYkf sLzzCfKpQdKzr0Ho47/+bXRlEvuur8p+KgjClkQEtCDcRFw9lrvK0v5vSCy3sCXoFs3dwSvu 0L2UU0WKU8+17UZjXyY/8RSEIcGJHxJVJ3Ee+F2Und7slyIIgrAKOZIKwk1CHMvtvvCvO+I5 zO1iYd+vkZl9BdAsj30VO1vs2DbS6fSqgBQRz8JGE4tn0zSxLKuzb8b7J8V9LO39GtnycXRz nsUDv4G2cwBEU0dxX/w/ieoLYikTBGFLIUdTQdgstAavcY13bcdyey//W7RbBdqx3Iu7foHC xadxs6PU9nyRVDrTESapVEo6bQhbgmQF2jTNVQI6lUph9g2yvO9XUX6DzNwRFg78OmF2BwC6 Mon7wv9BOH9SRLQgCFsGmUQoyCTCTSBcOod36D+iW2XMXZ/Aefj3MFRvR5XWGv/9Jwk++PvO dc0dj1HP7pNYbuGmo1foSpxc6Hke2dnDpKunqOz+AsWFwzhLx9srKoV9329i7X9c9mehg0wi FDYL8UALwgYS/zDxj/4/6FYZgHDqKP74Eey9j1w26F8plrsw/Tzl3b+Azo+Sklhu4SahV+hK 8rrWzkfxnX5KE09R3vE42fQg2amXIIrwj/4NujqJde83Ucrc7JciCMI2RgS0IGwQsXgOKlNE y+dX3Rb5LlEUdUTE1WK5s81Jlsa+jsr2k5ZYbuEmo1foSnKSqzd4J0upIsWJH9Es3UWw/+sU Lj4JoU9w5nmi6lT7rI2dk31cEIRNQTzQgrCBRFFEcOHQ6isNA794kDAMOyI7rEzivvCtjniO MoPM7/91UotvY/rLLO/7OmZuYNWErGSbOjmFKWx1ksLZsqyOBSmdTpNOpzHyu1nc96ukaudR lfMsHvhNolQRgGjuA7wXvkVUnRarmSAIm4IIaEHYIGLvJ1Ovr7rey+/DM9Kd5LZg5hjeS/8X urEAtGO55/d8lb6pHxPaeSp7v4KTyXeERiqVwrbtVeJZEG4GkpXnpIiOFztbYnnf19GGQWbm ZRbGvkGY3wtAVJvDffFbBDPviIgWBGHDkSOtIGwAsXgOFk/DSmxxTCN/J2EYtidWnX8B//C/ B78FtGO5l4d/ltL4D2kU76K5+3OrBEYsnpOeZ0G42YhFtGmandj5TCbT/oGYzlAf/QKtvgMU x59iceTzuEOfaK/ot/AP/Qf8U8+IiBYEYUMRD7QgbACxgI7GX1/1q1UrE7d0BzbA+98lvPBi +wYDart/DtcsUJp8RmK5hVuetUJX4sUbeZAwNUBp8kdUhx7FHx2ib/I50Jrg2N+hKxPYn/gt lOVs9ksRBGEbIAJaEDYIHUWo2aOrrqtn96OUReb9v4bFD9pXSiy3sE3pnlwYXxfv537/QRad PKWJp2n1HWD5wDcpXvg+RtAivHgIXZvBeeQPMdJF+U4IgrCuiIVDENaZTt/b2ffAq626zc3t Z+DUf0GtiOcoVWDxwG9ilc+RakywtP8bmH07LrNtyGRB4Vale3Jhd+iKyo2wtO8b2O489uJ7 LH7sN4gyAwBES+dwX/gW4dJ5sXQIgrCuiIAWhHWmY9+YXD15MDId+hdewWzOARBkdzI/JrHc gpCcXGia5qrJhel0GjuTp7z3K4R2ntzkj1kY/Sp+8WMA6OYS3k//DcHE6yKiBUFYN8TCIQjr SHwAjwIXNf/uqttU5IP2AGiV7qA8+Cil8adpFu+gNfIIqRWrRnKioMRyC9sJpdQqEdztjW7s ehx/4RjFiR+yvPMJ8ukh0jOHIfTxX/82ujKJfddX5fsiCMINRwS0IKwzURQRTr2NEXirb1gR BpXBh2hm99M/+TTV4ccI+j9OynFI6yZOdRxzfh7LtDDHHkPZBREDwrZircmFcYXaHbqX5VSR 0tRz1AZ+Bn/sy+QnnoIwJDjxQ6LqJM4Dv4uy05v9Um4ZgiAgDEMajUbnuiiKOn/ncrlVHvZs Ntux5AjCrYKh5RzXtie2GHiex5myRxAEnUAP4fqIooggCPAO/0fU/PHVNyrFzODnUGhK5bdp FQ9iRT6ON9+2dQTu6rv3DeM88S8xlCkiWth2xGNSFEWEYYjneauWqLFEceIpvMwOguJB+s9/ D8OvA2AUdpP61P+MkR1Y87sTeXX8I98mXDiFOXwXzgO/i7GNRXelUmF+fp6FhQXK5TILCwss LS3RbDbxPI8wDGk2m537R1FEs9lEa90RzNAW0Ol0utOisFAoUCgUGBgYYGBggFKpxPDwMPl8 /iNtZ/zDyrIsPla8lMYqY6Sw3oiAFkRArxOd97W+jH7+X0AUXbrRgJYzjBOUUaG39oN0YT/+ v2L2HxD/s7AtSYroeMxKLr7bJD/5D5hhi/rOz9A//gPMxgwARqoP+6Hfxxy6/TJxpbXGP/Yd glPPdq6z7vgS9l1fu+WFmOd5NBoNyuUyFy9e5Pz585w9e5aFhQV83ycIgs4x4WrE41KUHOvW IBa9cYDO0NAQ+/fvZ9++fezbt4++vj6y2SyOc+W2hCKghc1CzqcIwjqitSacfB3VfUDRkHbn PtyDWQ6B048RRdK6TtiWJPtCG4bREUtJi0d1zy+SnX2N/MWnWRz9EsWFwzhLx9FuDe+Vf4d9 3/+Etf9nO98frTVhGBI2K6ueK7jwCuqOr6xqqXer0Gq1mJyc5Ny5c3zwwQecO3eO+fn5y+6X TIns1Z87+UM+mYKaFNCdBFYuvdfxdVprXNel2WxSLpc5ffp0Z73h4WEOHDjAXXfdxZ49e9iz Z89VxbQgbCQioAVhnegcOKbfvK7Hiaw0fnYX/t4nSGsLM4qkwiJsa5JCLv47eV1r56fwU/0U J56isuNxsulBslMvQRThH/1rdHUC695vYhjqUkpo6XbMicOXnqRVJpg5hrHz3lvi+xaGIceP H+fNN9/kwoULTE9Pr/Iwxx1PTNO8bMJysiNK8gdMvF7355D8uxfxGYROAuuKJcf3/c7ZhLm5 Oebm5jh8+DDZbJbdu3dz4MAB7r//fu6+++51frcE4eqIgBaEdSA+1RzW5lHL565tHWXi2QO4 zgCePYhrD+A6/YRWH7Zt05fqww7D9d1wQbhJiMVZMo0zFnpKKbyBj7PkFChNPEOzdCfB/q9T uPgkhD7BmeeJqlPYD/0e2kwTBAHN/EGyprPKUhVefAVz5O6b2jJVLpd54403+MlPfsLMzAye 1359Sils2+4syd7yySX5vhqG0RHZsVBOXu4+G7AWne5EK1Xozo+YFbtIEAS0Wi3q9TrNZpNW q8WpU6c4deoUL7zwAjt27OALX/gCd911F4ODgxvyPgpCN+KBFsQDvQ5orQmCAPeDp1Cnnlx9 owGemadlD+La/XjOIC17AM8qYBiXV3PiPrjZbJZ8Pk8mk+mIBkHY7nRPLkxWMV3XJWiWKU3+ iNDqwxu4j9LF76PcMgBGbhjzoT/As0tUq1XME9+lb+ntSw9uWqgn/hVONn/T2aYqlQqvvPIK L774IlNTUwAdO4ZlWdi2jeM4HeEbC+FYIMeLbdsdsd1doY7HoVh8d1etoT2Oaa07/3d/Xskl KaDjxfM8KpVKR0x7ntexhAwNDfFzP/dzPProowwPD4sHWthQREALIqDXgU73jVf+73Z1yyzR UEUaZhHXGkCrSwI4WbHpPl0aH/AcxyGdTpPJZDphKnKAEIRLxNXMpIh2XbdtDfBc+qaex3KX qO38LAMzz2JWx9sr2mmie3+LWmov7sz7DJ/9f1c/8D2/gXPg8ZvmOxdFEYcOHeKpp55ifLz9 GuNER8dxVtkz4vElFsqO43Qq0vF9nZV+9MkJf/HlWEDHHumkkO71gyM+piStG0mhHAQBvu/T arVW/QjyfR/f92k0GtRqNarVKtVqlSAIANi9ezf/6B/9I37jC58RAS1sGCKghU0R0FEQ4C0v o3WEky9g2DbKNNft+TaS+P30fZ9arUalUqHRaHTe1+5Tzd2COVn96a4YxQe7m60aJggbQbKy GYuxWER7nkdq7k1yy+9S3vXzFCrvkJo/2l7RAHffL7KYv5+h9/8U2780oVCXDmB/+n+5Kc76 1Go1vvvd7/LSSy8RBEFHOGcymc5YkrRuxII5jklPRqbHwrlbQCeXXpXnbn86XG7ZiD3QcT/p pIhOfmau69JqtVYtnufRarWo1WosLS1Rq9UIggDbtrlzuI9vfetb7NixQ8ZHYd0RD7Sw4QSu S3N2Br/SPkg1FxZw+vLYuRxmJoPpOBhb/EB1NZKzzJVSnQNQ8hRpUiwnD269RHWvGfCCIKxm rS4R8d/eyAMEqX5KU89QHfoU/ugQfZPPgdakzj1N/8Ak9fzHKS2+dukxl88S1uYwizs7P4C3 IlNTU/z5n/95p5NFOp3utIGL7RaxaM5kMp3bU6kU2Wy2c12cfJpKpVb9cI+tHN1V5uSZtG6r Rky31zmuQJum2Sk2xKI8Kfzjs26xkG40Griu2xH4fX19lMtl5ufnaTQa/OVf/iULCwv86Z/+ KaOjo5vyOQjbBxHQwoYRRRHe0hLNhXnMr5eODwAAIABJREFUxGQ4I4qIalVa1QohYKYz2Nks dj6PmU5v+apPL+IDi2VZpNPpjtewl4DurkgDlx34uy8LgtCb+DuStFwkJ7f5/QdZsPOUJp7G 7dvP0oFvUrrwfYygRXrxHcz08GWPGY4fIsr/ypYdi2q1Wkc8K6XI5XLkcrlOlTgWxrlcjr6+ vk6P5b6+vo5ITVadk97n7gmFvWwZSbEc2yp6ieZk9Tm5JC0d0UqbTtM0O4+bHE9jAZ1Op2k2 m535IfPz85imyZNPPsk3v/lNvvOd77Br166N+xCEbYdYOIQNsXAErRat2Vm8WhXTMAjDHo32 DVCGwjQVfhCAoTBTKZxiETuXxbBsTNu+Ydu0XnQ6cKycmowPHL2Ecndf25i1LguCcG1cKXTF dV1Ct05h8hk0isbgAwxM/D1ma6m9rlIYyd7tmUGsJ/7llrRxaK3527/9W55++mmUUhSLRbLZ bMevnMlkKBQK5PN5CoUCxWKxI5zjCnTSHnYtYjn53gKrxHC3SI5FcdKjnrxP/PeVBHZs99Ba d8JdYqtHvLRaLV747t9w4sQJwjDkn/2zf8af/MmfyPgprBsioIV1FdBRFOGVl2nNL2BGYVsY X8vDGmAAGAYGBpGOMLNZnL4+zFQaK5tFWVv3BEryAJOsoohQFoSNoyP2oohw4TR+GOLb/bRC o+O3zU2/hNMYZ3nk85TmfkK6dqH3gz3yT0nt+PiWm6B2+vRp/uRP/gTP8ygWi+TzeWzbJpPJ dETz4OAgpVKpI54zmUzHzpE8ExazllBOjmlJYXw14XwlAd29XvL5kyTHzl6R7q1Wi8l3DvP8 889z8uRJRkdHefbZZ7nzzjs36JMQthtbV4EINz1+s4E7O4dfr2MA/jXEu3bQKzpbazS6Lahd Fx2E1Px5rFQKI5XCyeexMhmUZW0p33TyNPKVbhcEYf0wDAN0hPfKvyVaOI0BOICTyhNmhvCd QTynhMceBqaeYn7wcbJmiVL57cseK5o4RDR8+5azUv3kJz/B8zwcxyGfz3c8zf39/QwMDDA0 NMTg4CDFYrFj10hWmZNnzIA1xe5a4vlahXL3YySFeUx3OEt3b+nu/w3DWNUCb8hoUSqV+Pa3 v83ExATf/e53+eM//uMN/0yE7YEIaOGGo8MQN1F1Bk0UXWc1W0MQhARBiKEMjMAndF0alQqY Jna+Dyebw0inMG1nS3T02EoHWUHYjkRRRDh/kmjh9Oob3CqmW8XkLOnE1bsnv4tvFWikdpJ1 p1etomaOEvrfxDSz67/h14jrukxOTgJ0JgFmMhlKpRJDQ0Ps2LGjU31Op9Mdiwas9ip3C9/r uZwU5N2V7CS9Jnwmw1qSc0aSwrk78CX+EaCUwu4z2blzJ2+++SbPPvssL7/8MpVKhUKhsLEf jLAtEAEt3FCCVovW/Fynw4Z/vcK5BzrS+FF78McAI9T4y2WC5TLatkjl+lCZNFYmi7JtMAx0 FGFuYcuHIAg3lo6QM5wPsxK2X8amfPltQYtw6ijRvk9tmSr0wsICy8vLnU4/sXWjUCgwNDRE f38/hUIB27ZXzcvoNakv+XfSl5wUx3GVOimOk+I7KZSTgrlXomFSEAM9kxB7CeheyZPxfYYH MgwPD/PQQw/x7LPP8uabb1Iul0VAC+uCKArhhhAGAV65jLswj4p9vxvhrtfxQK3RgPIDdK1K Y2mRdL6A26gzOz5Obvcoe+6+ewM2SBCErUAnVCU9TLD3CZzJlzBC//oedOo1or0PbxkfdK1W o16vA+2KblJAxxMFAXzf74jbeI7LWkK5l7juJZTXsl90T5bubsF5rUK5V6W5V7eipIgeyufp 7++nr68PaP/AiKPLBeFGIwJauG78Vgt3bg6vUsZUiqBXh40NIooifK2wMhkWz53l+Ms/ZbnR 4P4v/dKmbZMgCBtLsgoaBAGVoUdpZO6FxhyOt4jjL5Pyl7D9JRx/CSMKr/KIbYzFD4iay+i+ wS3REzpuPRd3Fonbz8UWiDAMcV23p0VjLc9y92Wgp1i+mv2iu01nr5ad3b3uu++TrPR3J7Z2 t/eM10mlUhw6dAiAXC635jwUQbheREALH5koDHGXl/GWltArv/J7tqfbQMx0iqDZZPLYMU4c PcpytUKh1C+DqCBsQ5IiC0PhOwO4VmmVvUBHEVZQJRUskvLLpIIlHG+JVFhGhV3Vy0gTTryG dccvbuTLWJM4URCg0WjQbDYBOl2Vms1mJ+DkWqrKvbzKa/WC7lU9XquqvJaAXquq3C2ckyRF fVLYK6UIswZHjhzh5ZdfBqCvr6/z/gjCjUYEtPChiaKIoFLBLZcJ6nWUMi6rUGw4ysDKZKhN TnH81ZeZmZ0l8H3sLdSZQxCEjSGeWBbbGtLpdKeHcOzl7YhHpYjMEg2nSL1LSNphnYw3gxO1 yOgqmaiMOfce0W1f3DI2jhjf95mammJgYIBWq0W9Xl+V9ncl+wWs9iknJ/F9GJ/yjRLK8WeX 7A7Sq4NHUkRblsUHH5znn//zf87CwkJnewVhvRABLXxodBBQvXgB5ftElkVkGBimCbRbRrXv tDHbYhhgOik0cP61w5w/cYKFxUWUYWCKeBaEbUss7BynPYnQtm183++EcvRqwdYd+qG1Td0p 0FSKumWRzWYpFotYif7uWwWlFOVymRMnTpBKpUilUmitsSzrsn7zvSrJvYTu1arMa/mU4/vH 2xU/b69e+NBbHEPvgJZevm3TNCmXy/zp//4vOHLkyAa948J2RwS08KHRQOj5+M060UriiZVK YzpOO/jENNspKOs8kdBQCjuToTY/z4lDrzI5fhHP8zDVSrN9NAZbp0IkCMLGEYu0uGuD4zg9 /b/dUdLdFep4iUVit9jbClVox3EYGhpienqa+fl53nrrLe677z727duHaZqd5VpaxV1LlTlZ lV6rqrzKPrNC0n7RLZa7u4DE94l/7Kw1wdEwDE6fPs2LL77Ic889h2majI6OcuHCGoE4gnCD EAEtfGgM2gOlNkwI2rPag7BB0GiAZaEsC9NJrQhqfUlIG9wwQW06NhiKi+8c5eTRtygvLYNh oNTmH8wEQdgaJAONYtHX7fXtlYa3VkU6KUS3gnBOcv/997N3716OHDnC0tISr776KvPz8zz8 8MPkcrnO5MJeAvlKQvla7BfdKYGGYaxKYb0WoRyfGbhaK71kdbrVanH48GHeeecdPM8jk8nw y7/8y+Tzef7iL/5igz8BYbshAlq4ProPIkFAFARErkugTAzHxs5k2pVpQ12K6NYRH+UMqGlb GKaJ22jy/ssvMXHuPJ7ninAWBKEnSZG3avJg1+XujhO9fLbQrmh3R19vNrG4/+xnP8vAwACH Dx9mYWGB9957j/HxcX7mZ36Gu+++m127dpHJZAjDcM3uF932i14iufu1d/8Iia9bK5mwO8mw V3eQXsmI8We4sLDAyZMnOX78ONVqFYB8Ps9v//Zv88ADD4iNQ9gQREAL64PW6DBANwPcZhPD tLByufbgbNtoQ61ob42+xrAVZZqgYfbsGU6+8QZzMzMYSqrOgiBcG91e4Jju0I/k9d3BIN0e 4q1CvH333nsv+/bt45lnnuHChQtUKhVeeOEF3nnnHe677z7uvvtuDh482OmVHJP0Kicvdz9+ d7Q3XF5VTgav9AprWasK3X3/GMMw8DyP6elpLl68yOnTpzvC2XEcRkdHue++++iP6h2fuyCs NyKghQ1BhwF+tdJOBHScdvx2JoNh26DDS9aOHjYPQymUqfBaLY6/+gqT587hS9VZEIQbxLUI 6yuts5UIgoBcLsev/MqvMD4+zsmTJ3n//fdZWlrihRde4PDhw/T39zM2NsbDDz/MnXfeiW3b WF1Jrd2CFlizWrxWf+mrCeXuLhvdLerCMGRiYoILFy4wMzNDvV7vBKOkUinGxsb42Mc+xsjI CKZpEsxUpPOGsGGIgBY2jtgbFwTg+7iuC0phZ7KY6RREESizfT8AVio8ymD27FlOvHOUxelp DLZW5UcQhFuTm3WciSc97t+/n7GxMR544AGOHj3K6dOnqdfrTE1NMTU1xZEjR8jn8+zbt4+D Bw+yf/9+crkcfX19Hd907E2OY8C748B7ecevJJRhdZs6wzDwfZ9Go0Gr1aLZbDI7O8vCwgJz c3OddnzQ7qSSz+cZGxvjtttuo6+vb1Wfa0HYSERACxtPXNXRGsIQv17Dr1VRtoOdyxGhsRwH lMKr1zh/7D1OH3+PoNW6aQ9ogiAIG0lSVA4MDPDFL36Rxx9/nA8++IALFy4wPz/P0tJSZ3nr rbcAKBaLDA0NsXPnTkqlEqlUikwmQyqVIpvNkk6nSafTKKV6TrZMCuh4O+L7NJvNzuK6Lq1W C9d1qdVqLC4uUqlUOtHkMbZt09/fT7FYZM+ePezevbvTUSVZHZdjg7DRiIAWNp94oA18/Moy YQQ6k6JRrfH2669Rnp1FAdKRThAE4cMTt4OzLIsHHniAhx56iGq1yuLiItPT00xMTDA9PU2l UqFcLlMulzl9+nRnfcuyOkucfhhXkJVSZLPZyyZpRlFEo9FYJaR93ycIglX9uLuJq8z9/f3s 2LGD4eFhCoUC2WwW3/c7YThbrQ+3sP0QAS1sGdqn+sBQBpHnU5uZZml6Gksp9EYlswiCINzC eJ6HUopcLkexWOTAgQOdCX+u6zIxMcH4+DhTU1NUKhWCIOgsjUbjuifoKaWwLAvHccjlciil KBQK7Ny5k5GREYaHhzvhN3GVOwgCPM+TyYHClkIEtLD1iCAyNRgrwQUingVBEG4oyQqwUqpj 1RgaGuLBBx/s9Mwul8ssLy9TrVZZWlqiUqlQq9Xw/XYGgNaaZrN5mbg1DINMJrOqF3ehUKCv r49CoUAmk6G/v59cLtfZlnjplRYpCFsNEdCCIAiCIKwKNIl7Rff39zM0NIRpmp0e2N2dLlzX XdU/OyaVSmEYRicgJbZweJ5HGIYdS0ayY0eyG4cgbGVEQAur2OWE+EawahJIN4HfIlycICgv 4/fwsF03hoGhDCqnj7Pw0x+hrmswNcgPj5B64G6GzU8SRD6mYWEqaXUkCMLNTcVd5v2fPsvi 4iKPHNyNvXcIvdLmLUl3j+dkMmMcnBJfF4vk+LIKL0V3d8d/x5fzSmFYl5IIgbZXuV5t+6RX KstGFKGCALXigzbDEHNFVMeLXlk6oVxhSLgi6JOV6eTxKd4e27Y34F0XhDYioIUOychWWLsH qjKMlWWd4mwNAyMOKrjehwKUMjAMqHgVpufH6c8NUurrJ21nZOa2IAg3Ld0pgWtFjMe3d4fA dF/uFd3dK9a7V5hMd+AMXPIw94oBT97W6/mT94kvx23vul9j8vUJwkYhAloALonnuJn+lU6j qSDAtiwMy1wnf7KBYRpYykRhcD15KQYGCoP5+QmcxXO4foNmuc58Y4ZCpkRfKk8p10/KTq9K IBMEQdjqOI7TEY3x+N3LL9wtoHtVoC3L6lwXX07Glier1Mm4727RGh83YsEbV42VUoRh2DMa vPtxkj2iY5LrJpMKkx7rXsJaENYLEdDCqgHIcRwsy7qiBy3QmrTjEDgOar0q0KYiZVlYhsF1 yVoNoVun2ljGTCscHAxloIlYdhdYbM4xV8/Sl8nT3zdIKduPY6WwTPlqCIKwtRkcHCSXyzE3 N0e5XCabzfa8X3el+UoCOm5Xdy0CulfVNz52xL7npKc6DmExTbNt4UhsR/Lx4+cIw7Dzd7y+ YRg9o76TVezl5WUAstnsZQmLgnCjkD1LAC5VoLt7eSYJggYYekVkmxhXEdrXsTEYpsIyFcoA dZ1PoTQrj6UwrUty3MDAtGxCI6DiLVOeXyRlpymkSwzkh8il+sil+8QvLQjCliUMQzzP4/jx 42jdHp+7q9BrCWjLsq5JQCdF7rUK6GQFWinVqUKvVXXuXr+7Ap18rm4B3f147733HgCNRkMS CoV1QwS00CEeoHqJ4lZrlkbtNBgRpp9D46N1tH4V6BWftcH156cYXPqBoHvaNNp2FUMpAgIW W/PM1aZxVIp8rkAu1cdgfphipl9sHoIgbBk8z6PVagHw9ttvc+jQIR5//HGazeaq+/XyOl+L 5/lavNBXE9Dx5fjvD/M8sf95rSWJYRikUilefvllzp07ByCBK8K6IgJaWIUGWOU782g1ztFq jmOaGgyNH9WIohZhqFfd94ZhGO1FqfZkwusZADUYSoFSlx53zbteir41lEmgQpZbyyzU5pla niRlpRnIDzFc2EHaTpOy0x99uwRBEK4TQymUaWIoRct1+bNvf5tdu3dz2223rRbR8di3XkvP jTPW/7kTpNJpzp45w5NPPtl57VLwENYTEdDCKi7WL7UHCvwabmsGHVXBKBF5ERigvYh6wSI0 PK5rht+atCcRNsd8io/9/PW1sdNgZTOo0buoM0Bk+Ne+bnyG0ABDK4wAZhfLnFiskrIz5NMF cukcGSeLZUr7JEEQNpYlI8vHH/s5RpaWsEwTz/f5u+cP8eXcEGNjY50KbHflttuGscoPbZiY mBjawIxMFAojMlCR6rS0g7i7Ua8KdPv/MGzfL4oMosggDNsV5VBbhIZNoAJCMyQkJDACIqvd Czqwg1W+6SiK0GEIUdRugxeGGFpjJCwcpmkyPjnJX//1XzM3N0fKtnH9DzHWC8JHQAS00CH2 q4Whj+/OEgSLmAqCKOEh0xBpjY50W1+uiwcaDE2nv8eNeIZ2V5G1e1tfff1L70FkRLhhE7/p MVuZwlIOmVSWYqZIPlPEVIogDGUioiAI60rsA3Ysi/v2jfHexXYE91/91V/x6KOP8ulPf7rj iY6FdNJaEXdbiifmdbeNix8/Xic+RiStfmuNqclQlNizHG9H/H/ycq/bux+nO2hFKYXnebz6 6qucPHmSCxcu0J/L8YldO3np1Ol1fe8FQY7wAtAepMIwxHWXaTWnQLfQWuOGXRM1DNBBRBC1 Z0Svj4WjXfENo4hIc31dOGgL/ijShEFIdKMmlKzkxxiGAjwqdY9qvYxSJpOT4zQrLk98+guk U2LzEARhfeik9wEf37WLu/fu5fuHX2OpVuP555/n/PnzfPrTn2ZsbIxMJtOp6saiOfm/aZpE UdRpTxdfTk4E7NVD+qrbtnJsiQVyshtHfDlektHdyf+T60O74txoNJidneXtt99mcnISgLGB Af7po49QbrV4XgS0sM6IgBZWBjiPavkMtUoNTTv5qWdhwQDtR/hBQBCG1z/DrycGhooIwohQ X3+naQNNEIX4fkAU3vjkRAOFaSpabou33nmD9469x+177+AzDz6OMsSDJwjC+uB5XkdAu0HA w/v2UXg8xY/fe4/jF8c5e/YsExMT3Hbbbdx5550cPHiwI6Th8lCTuHVc3G0jbiPXPdEwXhfW 7gMdi92kcI4vB13Jgt1iuVtQJ0V/q9Xi4sWLnDlzhomJiXZ3D2BsoJ8/+OzPsr9Y5McrkwgF YT0RAb3NiaIQ31ugXjuN75XRFPFcD63XODVngA50W9yul4A22vEnoY7QQHQ9ElprojAi9APC IGx76W4URjuNUaM5O3WGI4dfZ3pqut0ez7QIVqosgiAI60GyRVukNW7gM1Iq8uuPPcprI2d4 +f0PWKpWee+99zhx4gQDAwPcfvvt3H333fT395NKpTpCOO6xnBTAcVW6uyUdrO7skSReP962 pICOq9G9lm6xnLSWBEHA8vIyp06d4uLFi5TL5fa2ACP5PI+M7ub2wQEKp9/FlbZ1wgYhAnob EwRN3OZFms3zKAN8PyDwQ7SGSEdrmo9X+9DWQ0FrWPErX88zxAN5qlQkM1Ra5au7rq3TGtO0 sE2bWr3Cu++/y/F336NWr7UPLqrd0eN6PNeCIAhXozO+JMbkIGxP9n7wwAHu2bOHE9PTvHri BPOVKrOzs8zOznL48GH6+/u54447OHDgAP39/ZRKJfr6+jqPnRwvk17oj+KBvtoCrOpNXalU qNfrLC8vc/78ecbHx1leXu4UJBzLYqCvj0/s3MFtAwOkzLaY98MQx5S+/cLGIAJ6O6IjfH+J VvMCbmsWpRS+3+7rDCsDol57fmBn0NN6nfSzgebS838UCaq1RpkWA7ftY+Th+8iODN0Y+4YG 23ZQGEzNTvDGW0c4f+o82tCrWibF2y8CWhCE9aJ7fNHx5GsNIRrHsrh/7xj37t3D2dl5Tk1P c3pmhvmlpY6Yfvnll8nn85RKJYrFIjt27GB0dJSxsTEGBgZWeaV7tYVbqwLdnSmQ9FrHf8eW kMXFRcbHx5mdnWV+fp5yuUy9XqdWq60KTBkp5BktFPhYqcRoPo/CICQijDTSsU7YaERAbzOC oEmrcQ63NUk2a+Oy+jTgTc/KgJ3tLzLy4P0M3n87yrSIboCVwlQmjuVQbdZ4/+R7vPvW21Qq VUxLKh6CIGw9NBCuBF7dObqbj4+OslCrMl+rcWpqmpMTEyzX65TLZcrlcme9TDZLOp0mk05T KBQ64npkZITBwUEGBwdJp9sTpNcS1t2+Z9d1mZmZYWFhgcXFRSqVCouLi9RqtU4gTBwKE2Mp xUBfHwcGB9lXKtKfTlNIOUD7jGnI5WmEgrBRiIDeDmhNpAMCv4zbOEsYVTBNTb3evPq61/DY 69KJQ2tCP544co2rRBrTsijdtp/dj32SzHB/e/C+AeLZsVLYpsX0wjSvHn6Zi2cuEhGKeBYE Ycuj0bh+gKFgoC/PUKnIHaOjBA8+yEKtxtnpaS7OzjJbXqbpejRbLZYaDZag0+EiJu4Znfw7 l8tdJqLDMKTRaKyqIMeCuheObVPI5cg4NiN9fYwUCuwrlejPZjp9n6MwIgyDFXufnN0TNhcR 0NuASHvUKscIgmV0FIvSj36+yzANnKE0njLQXoj2oxsvpI129eTDiGc7myF/70FGH/4EdjpD GISYhok2YkvFR6hWGJAy25WWo8ff5Ng7x5ibncUwFcZ1N9gTBEHYWMIoJArbLTgtS7FroJ+x HTswbQutFIvVGvOVMgvlCtVmk2qjQaVapd5sUq3XqTebl1WKXde9pufOptNkMhn6MhkyjkMx lyOXcuhLpRnoyzGQyVBMp4iClTZ3vr8iukOiSBPp65pSLgg3FBHQ2wCtQ+r1M6Qcj0YzwrbS QBbbTqGUJghCDENdm6heUbX2QAq75BC5EWHdx68HRHV/RUyv3Pe69LRxTeZnrTXKMMnu20n/ g7fjDJeoB3V0uY7jpHBMG6VM0naKEANoD8LtWeVXFtWWaZFN5ZiYHefIG69z/sxZ/MDHMEU4 C4Jwa6A1+FFI6IMyFQPFAjuGh7BsB2WaeFGIGwR4YUjL8/GCANf32/5mpQiCgMXlJcIgHmFX JlorRX+xgGUoojDA0JCyLRxD4ZgmlgEppTAB7ft4nkfgB4S+S7BSbZYqs7CVEQG9LVCASRD4 REELL2phGDWCwMK2cyiVAR0B7dNycf/Pq2IaqKyJyppY/ZrIi4jqPl7ZQ7vtyrSO2pNPbvRk Q70yS89J59h5z6MM3HMfOh3hhssENNFGgOs1cDEwlUXLb2CZDlkni8LEYGXyi1JoHa06rWgo hWM5REHEW+8d4Y0jb7K8uIRhGhgyU0UQhFsUDURhhOf7+FpjKBPTskinUmQtC2VaGJaFMk2M OEhlZXLgZR1BoggDjQ4CojBs/+/77aqy7xP5AaHvtSew+z5hGBBFoUhm4aZBBPQ2w1Btkay1 j9Y+rtsiDDUYDlqniHQarW0wNMpg9cDYTeJqwzQwsyZm1sQaSKG9iLAeEDR8onoInkZz49rI KUMxsO8udt3/OLmRPRCBDiDFACEegVHHN+qE1PFp4vkhnufTcpsoQ5FJ51AYOLaDqSyClWhB A0UmlWFqZpJXX3uZyfFJfD/AMNclMUYQBGFLo2knueowQhshRtBuc2oYqt2zv6uooHUE0Uob zzBaEdABOmwnwUZh1E6HlTafwk2OCOhtyyVBqBSEQQvPrxNEGcLQxDAUpplF60uN8o1rFNSG aWBkTKycTVrncGsus+MncReblFK7UIaJIq5KfwhhqtuDue1k2Hn3pxi559M42b6VeO5o5VWZ 2GSwdYaUHiA0WoRhi8Co4VIm1B5RFFFtLAMGKSeNrSzSThbbtAl1yNvvvcXRo28xPzePMhXK XLulnyAIgiAI2w8R0AIAhjLafTQj0NojijS+76JMhamyKOW0b0ShlIFh0K5K9FKWGizLBCzK tVlOn3mdmelJCEMsdYzh3AF2F+7HBFTociktZW0xHT9Paed+Rj/5c+R3HwAgCvyue0arLNiW zmKTJdJFMuwkUE1clgl0nchwcb0mroJW2ERpxZtvvsWZU6fxfA+14nUW8SwIgiAIQhIR0MKa GEaEjiKCqAJaY5gpDMPCVA7KTKO1vzIZL1olMk2lCIOQC+NHOX3qGM1WHQBlGGRyY2SHHqOV 2YcZtlBBHTOoYXpVVORfJqT1SipAXHXecd9nsJwMOrrW3tXRij43MLBIRUUcimgjINBNQtWk Wl9kvlojN+AxOzuN57oyUVAQBOEmRQx3wkYgAlq4NgwDtIfWHn7gYph1lOGgVBz9GidVQbNR 5fj7rzIzO0kU+YDGsTPsGPoM/aVHMK0cOgoJrWx70QMYaRcV1LG8JVTUwlyJ8wZNYWiU0Qe/ QHHP7YD+EOL5cvSK1UNhkbVKlJdtXn/pInauzj0/m7osVUsQBGGrkkqlsG2bSGsaroeS8QsD qLgeANlsdlXPakG4kYiAFq6ZuMpsqBB0SBh5RFEdDBvbKRJFMDNzhvePH6FeX27f11AU+8bY OfIE2dztoEN01LZdGJ2obhNtZYnMLEFqEDNsYvpVSM2z4+DPsPdTX8LJFoiicEVUXx+mbRL4 ISdOTXP48AkWK1UO3tF39RUFQRC2EHH3oCAIuDA/z2fu/Hinldx2xVSKN6amgHZ/6rWCWwTh ehEBLXxoLtk1jHZ+Cj6hv8xyeZas5JAVAAAgAElEQVSjb71CGPoYhiJl97Fj+DOUSg+jDLsj nC8nWjXih2aO0MqR/niR/aaNYVpE4VrrXjumUijLYHGpxiuvfMC58RmiqD2bXOo2giDcbPi+ j++3x8azszOcnZnlwMgw3rW0Ib0FSZkmr01O8s7MLNB+f0RAC+uFCGjhumkHkoAOAwwjREea XGaMXTt+iVzfKIYR8uFqIm1BrZzMyhNc3wBoGGDZJkEQcuL9ad546xRzi2WUUihDEW3nck0P olaF4PSz6Nos5thjWLs+sdmbJAgbTrh4lnD8EEZuBGvfz2JYzmZv0hVpuh7/8O67/ManHyOX ShFsM+FoK5O5RoO/Ovo29ZWkRBX3qhaEdUAEtHDjMNpT9TDAUn2E/k6q5QaWFWFaDrYVYVr2 SpS4Aagrx2tfp3DWgKUUpm2wvFzn8GunOXnmImGosUzZ9bvRUYB/+scEJ54Ev30ACqffwvjs H6NKY3IgErYFWmui2gzuT/8NhO3+8MGpZ7Du/gbWnoe25PdAKQUozs/O8p1Dh/nKAw8wlO/b NpVo2zSZbzT4s0OvcWpunnYo2PZ47cLmISpCWBfak/VCwtAgDEwMAloqwrQiLCvAdlIoFVcI rHU5zebYJkHkc+ydKY4ePc1itYqBWjnYCDFaa8KZYwTv/i1RbabrRggWTmMX9wJsSfEgCDeK uM99MPt+RzwD6OYS/pFvE557Huf+38Qo7NlS3wXLchga3s/c7BlOT03xlz95ns/fcw+f2Le/ HWC12Ru4Thgr5rvXJiZ5a2qKoxMTOE6GweF7mZp4c5O3TrjVEQEtrCtG4p9Im0SexncVrhui zBa25aDMFqZlYZlpdJxwBVeuTl8BUymslGJxscobb5zlxKnzuEGEaVhsoWPepqO1Rtfn8N/9 b4TTb/e+k2kRFA+iwhDTNLeUaBCEG43WmiiKCHN74uSoVbdHC6dpPf+vsPY9jnX311DO1ph8 rLVmdM/9DA19jOPvPctSrc6Tb7zJ+bl5PnfXXRRzOZRpEnLz2zoMDJQy0JGm5nkcmpjgg9k5 gigiky1y7yf/CcpMMzXx2mZvqnCLIwJa2DDaOtoAw0RHEIRpAg8wWlimxrRcLDvCdvIoo10p NjDagS3XOPDbtklEyMlT0xx+7RTzi+3EQUvJrp5E+y38D35AcPYfYI3TvH5mhMb+L5O2ClhR hGmaCfuNINxaxGFNYRjipgbxbv8NsueexPSqXXeE4NyLBBNHsO78CvaBz18WZ73xaDDgjrs+ T64wzInjz7Ewf5E3zpzhg8lJPnlgP/eM7WX34BCWaRHehDVpA3CUSUDIVLnC8bl5TszP0/Da LetyfSM8/LP/GyM7H2L8/D9s7sYK2wJRFcKmcUmIZQhCCIIQ341omnUyaQvbzmCl2j08TUzC q/R/TmdtFheXeeXQKS5cnKXpeiKcu9BaE1x4leD4f0e3yj3vE1kZ5vs/Rb14L1knhxNFnVPb Ip6FW5l4P4+iiEZmHwtjv01h4TD95Tcxuscfv0Hwzv9HdP4lrHt/HXP445v7/dAQRSG7dt3J yHC7En3+7BvUW3VeOv4+b5w5y+jQEPeO7eWuvWPk+3LtsoRxyQqxlTBWzlwqw8BUJhXX5eTc HCfn5piu1mitdB9JpfIM73yAoR2fZOlsSBh4vRNyBeEGI+pC2BK0x0oLDeggolEHZXqkfBPT VJhWCMpAYa60zlMrZ1fblVHTCTn+wUXePnqeqdkFpOq8Gq010fI5/Lf/K9HSud53MgyW8/cx V3gA7AyOaWKaZmcmu4hn4VYn3s8Nw2gHcCiLhdLDLGfvYGT5EH3105etE1Um8V7+d5ijD2Df 82uo7OAmbHlie6IAZVncc98vsmfv/UxOHOP82SM0mlVOTkxwbmaG595+h10DA9x/8GMc3L2b TDpDKt0OZVmZnILeSFG9IpJNs+2aiYwIP4pouS6n5+Y4OTPLdKVC0/M63UVS6TyDQ/fSP3QP mdwIBoooWpDgFGHDEIUhbCHaVYNYqEUhNOshEKBMMFSE6YQ4jokybAylSKds6o0Gr718mhOn pmi2vHZfZxF7HaJWGf+d/0o48caa92mldzBfeADfLuIYAY7RImVqMiicQGM0m2jPBMO4hpO/ V3nvr/rZXG3963z+6+U6963Y479+z7/Z79/1bd/VN2+dXr8GtEbpEEdpMo5Cp2xaBPg6x9TA 58hm72C4/CqOt3TZ6uHEG4TT72Ad/HnsO355U9ve6SjCMAyK/aMU+3dz8LbHOHf2dSbH36Fe X6Zcr1Ou13n/4kVy6TQ7h4bYu2MHe0aGKeYL9JeKDPT3k81mwFgR1Mpof/+V4iPtIyu2PGWZ YKyM9kqhTZN6ELBYrVGuVVmu1ZhYWGS2XGamXKbhup2HsO0Mfbk8pcG7GBi6D9vOAgZRGFz/ 90oQPiQioIWbAIMoBB0oQl/h1iOU3cTJGJy7UOXNI2eYX6wSaS0dNhK029L9A8EHP4Dg/2fv zuPjKq+Dj//uOvto3yVrtWR5AbzI+wohjg0G2xBSyh5eSGiS9k1J89ImKfmkSVpC2obQDy1J SEiAsKUkgRAghDXYZjV4t7wgWZK1LyONpNnu8v4xmrGEbTBYq/18Px+BNXPn3kdXoztnzpzn PJEP3dYZbqMw/MxJ7zeGvgThbCADnqGvj8WMYRx4FrPxDdRZm1ELJq7tnR1vzg+A7vQya86F VM9aQ3dXPYGeZjo66uhoq2cgPMDhpiYONzUB4NR1vB4PKV4PHo8Xv89LWmoqKT4/mRkZZGRk kJaWisMx1KdflkdOthwqg7EtC2QTS4pvEwmH6OjqpicQoLOnh2AwSHcgQH8oRP/gIH2DgwyG w0RiIxfNcjg8pKQU4U0pwu3Nx+XOAUnFNGLx1WmRRPAsTAgRQAtTRuKFSEIBQ2WwL8LO7U20 dgZQJAVZXESBRFu6XRi7f4PV3z7RwxGEs44d6iH29n2Y9a+iz/kcckrhBA/IxjCiyLJEdu50 CgpmEIkNEB4M0Btooa2tjq7ORvp6uzBMg86eHjp7RmbZNU1DVRQ0TUNRVRQ5fj2WZQWfz4c6 VH9hE89PG6ZJMBjEHJqkbNkWRszAME0Mw8A0jOOmhsuqhq678XjT8fpySEmdhseXh6p6kRUX hmFgmAa2aXB2L1guTAYigBamJEmWsGJgWiBPspIN27IxDeO4FljjcuzkJCj7QyfS2LJMv6OA QS0H5Hids6LIqIoWrzmXFSRZ+sAEo1P7eT7sE/LT8xF7OM3z/dHPoLE9/keb6scf4/Gd5vGH //4TWw6fVGhaJpZhYFoWlmVh2+A0e/FEmo+fYJh4fN9RjK5DqL78SfHpmG0Tn2RnSWiKjjMt j4yMPCqmzx1qDRehq7OR1rYjdLY30T/QSywWJRaNYBgxotEIoaFV/oZr7+g45TFomo6mO3C6 vKiaE01VcblTSU0rJDW1AI8vD0lSMQwb0wLTjF9PY0Y0vl6AmCAoTBIigBamtMkTNsdJEvh9 qcysnIWqaeN+/MSLvZVeRXj+/8WuewlH86tIZnTkOC0LX6gRT7SFiJqBqXmRpPiMd4a+kkFE /BHj/JN80EQff4Kd9hvE03z8BL9BPe2Y6XSGb5OcsCxZNoploZkhXNF2FPP4YDJ+PIlYzgLs 8nU4felYQzXJk+qNvm1hW2CR+HRPQlWdFE2bQVnFHBy6gizbRCKDRMIDRCODDIb6CIdCRKID WKaFJINpmPQFAxiGdax1tm0jKwo+XwqSpGCaFpKk4HB60DQXDocHWXah615k1UksCtFYlFjM IBazMAwTsJKJABEyC5ORCKAFYRRIEmBLlBdP5zOrL6K4sGTcM06JjLNlWcRiMSLRGAOpc4mq 08hoexHvYP1xj5FNA5fZRliW6E2bh6X7idcUSh/c+WmN7bTjBpF1muBzMMXP/2mfu6E2jkYY X+8e3OGGk56SsCOLrtwLUVIKcZsySiwWnzw3dD2YTEH08eJvwI1YFGwJRZHQdQdutxtdlVE1 BVUl/qVIyTcm0ah17BMv28YaetOhKAqmyVCbUohGTWIxk0jEJBoziUYNotEIRszCNOMB85R/ rglnDRFAC8JpkiRwOd0sr1nJmqWfQtcdEz2kEUzFzdGsteihFnJ7tuKKdR63jTPUijP8DP2Z 8+nPWoqtjO7PIF4ShdPpzXsqQedY9v61LRNv97v4OrYif+DTnISY6qXNv5B+bwW6puMaGs9U 70lsWxamaRNFwrINDFNCMSSUeNIaSZaQh6X4Lex4KzrLJhozMQ0bw7AwLTAMi1jMxjTjAfNU PzfC2U0E0IJwGiQkKoorWbt6PaXTyiZ2LJKEPdSJRFVVHA5HvGYQkGWZqJRPvWMTKf37yel7 G8UMjdyBbePteBt3YB/hwguIZp03AT+FcKaaqsGS0nsYT+NzKKGuE95vyQpd3nPp9J2LojnQ VRWn04nD4UDXdVRVnSLZ50/OGv4W2bLjZS8TNxxBGBcigBaET0CSQNMcLF+4ipULV+Lzpkz0 kID4C7Qsy2iallwMQlVVNE0jEokQiUToV2bR7y4jo287Gf27j/t4W44N4K57ElfXuxjTN2L7 CibopxHG01QNcMeKFO5BPfwUcue+k27T5yqjLXURlu5HV1V0XcfhcOB0OpNBdCKAPlODZ0E4 W4kAWpiyJMZ/VntikkxeTgHnL72QubPnj/sYPkziRToRRCey0Zqmoev6sUBalulMX0rAW01u YBueUOPx++prRNtxL9LSryO5M0UAIEyY8Q7u7VAAe/t/QWzwhPdH9AxaUpYQduWjqipOTRsR OOu6jq7rydrnyTaB8MwXP9fiTaEwlkQAfVawkLCRJenYLOkpTkJCkWXkcVy2NZl1rlnJkvnL SE+d2CV7TybxYm3bdjIjrQz1b9V1nXA4jKqqRCIRDCWTRm0d3lA9OYE30GK9I3dmRJG6D6D6 c0UQIEyY8QyEbNvG6NyLfYLg2VKctKcsIOCpRhkWODscDlwuV/JN6vCs81j+zSTeHNu2jWGE xd8ngCRhGgMAeDwesbS3MGZEAH0WkCQNVUsjEg5i26DrKrZlY0zxSRyyJI1LAJ14TcrLLmD1 kgs4d+ZcVHXy/+kkXryHB9HDs9HhcJhwOEwkEiGklFPnnEZacBcZwe3I5tBqYBJY3oJkbbV4 gRYmwng975JtIF2ZHxwAAd9sOvzzsFUX+tAcg0TW+YP1zuNV85yWlobP56O9vZ2e7qNIsgJm 7KMfeAaTZYWu9p0AzJkzB7/fP8EjEs5Ukz8KEE6bLGukZiwkGqkgGm4nPNiIZQ8gyxE0TSUS iQ21D5paEv1Gx5IkgapozJ0zn1WLLiA3O3dMjzcWTlTWkchIJ74ikQjRqEKPMpc+TyUZAztx GEFi2fNwOLJRLCuZyRFBtHCmSiycEvEUYUxbi9a+najqp9M/n6iejqIoyfIMl8uVDKJVVUVR lBFvWseDpmmUlZVx+PBhOtrfJ9jXjseTjmUZ43L8yUZRNIK99bS1vA3AypUrcbvdEzwq4Uwl AuizhKp4UN0e3O4izJRqjFiQ8GAT0VgXNi3ouolhDi2sKiGmUBMPnvOy81m95FNTJut8Micq 61BVFXVo4tPwbHRUlunQl6KqKm63G82ykoGFCJ6FM9XwPuqWZdGfdh6DjkoMw0CSpGTWeXjg rGkaiqJMaJ3z+eefz1tvvUUg0MOeHc+wYPHnkCQZ2/7gQtlnNllWiMUG2fXOjxkc6KK4uJi1 a9dO9LCEM9jUjQiET0xR3CiKG03PwrIjeMKdRCLthCOHARlsE1VTMA072QbtTDfihU8CWZGY N2sBq5d8iryc/Ikb2Cj7YFnHyQJp0zSRJGncajkFYbJIPNcTn9IM//tITBJMBM7Ds84TJTs7 m4suuoiHHnqI5ua97HzvKeacsx5FdZw1mWhZUTGMMHt3/A8tR99DVVVuu+02SktLJ3powhlM BNBnMVmWkXGhuAtxOPNRtWL6egYID7YTifZgM4iuK1gWmKZ5Rkw+/DCWZRGNRUnxpbJ66adY WrMMTdUnelhjIvGCn8ieJco7tKFJUYYRf+FN1Euf6X1sJ6OGti621x5h48p5Ez2Us8LwPuq6 ruN2u5OfOiX6qicC6oko1/gwy5cvp729neeff573D73JQH83s89dT1paIYZx4oVfzgSSJCPJ Kv19jbQ0vcb7B54B4Prr/w9f/OIXJ3h0wplOBNBCkqp60HUNWfaiG1EMI4gR7cMigG30oigy lh1fo/VMCqZlIN2fzrSsDBbPjTGrYg7TCoonelhjbvgL//BAWtf1oTdMdjLLlggYhPFh2zav vneAR198izS/m5XnVonzPw4SmefEm0aHwzGi5GmytqXTdZ3NmzejqirPPPMMba2H6Ov7BeUV S6moXI4kKZxRdXlSvI2pZZm0NW2ho/UtotEQDoeD7373u9x4440TPULhLCACaOGEFEVDltPQ 9TRMMxfTGMQ0+wiH2kGKIkkWiiJjmtbxExCH2uVNGZKM2+emPK+S0pyKZLb1bPHB+mjbtpOZ t+FZtskUMJzJbNvGNE1e3XEAgB899gJ+t4vzpk8Tv4Mxlji/w1cPTNw+2f8OdF1n06ZN5OXl 8cc//pHW1lb27n6Bo407Ka9cRl5+FS6XL561lcyJHu7HJ0nIsgrYRMJBerr209m2g1CoG8sy yMzM5IEHHmDz5s1n3TVcmBgigBY+kqI4UBQHtp2Kw1mAYQSJRjoxjSCWPYjDqWIZMhCvmZaQ 8XqzJ3rYp0AGLOack8eihSXxW87iC+/wQPqDtwvjIxE8H2xopqUr3pPbME3+9YE/8v0vbKa8 IFv8PsbY8PKmE90+mSmKwrJly5g5cyYPP/ww7777Lj09Lbz9xm9ITcthWsk88vMrSUvPR9Mc 2BjA5A6mJVlGkTSMaISBYAuBnvfpat/NwEAnEH/jMH/+Ei6++GJWz6mY4NEKZxMRQAunLB5g qeh6PDNtWTEMoz9e5iEFsG0LjyedGdWfwaFW0XQkhj2Jr82pqU4+9alq5i8oQdNEs/2EqRAo nMks0+TPb+8fcVsoGuPbP3+SH37pcnLSU8XvaIxN9fOblpbGTTfdRG1tLTt27OC1114j0NNG oOcZDta+hs+bTkZWMSWl55CTU4ysDJWlyExcln3ok0tJkkBm6N8mPV1H6Oo4QG+gkVCoh2gk vkiKw+Fg6dKlLFq0iKqqqindJUmYmiR7Kq+kIYyKxOIB0WiU93ujGIaRbFt2qkwzwuBAG4Yh k5ZeSGtzmNYjMWJGdEzaKSmKgmka/GXbPo62tSBLp5o5lkCCWbPyWfvpmeQXpI362AThkzJN k2gkzC3/8TBdweNXwivITOOOWy7D73FN+SBPGB+maXL06FG2bNnCW2+9xcDAQHKSsMPhwu1O ISe3hPyCcnJyi3C5XLhdbtxuF7quoSggy0Nfko0s20P/Jn45lT/wPLTic2RMG0zTxjRsDMPC tMA0wTAS/7eJmWAaFuFwjMHBAcLRCKHBATo7GujpbiLQ00A41EcsFgbik5q9Xi8LFy5k2bJl 5ObmoqpqsmNQWcqxJdTF34cw1kQALYxKAP1BPV0RGt4fIBq24ldeAGv0Vj78ZAG0hNers3zF dFaurETXRcZCmDziyzEb7DnUwLfuf/qk280ozuE7N27EqesiSBA+lsHBQd5991327dtHY2Mj zc3NI1qVyrKK359KRkYuOXlFpKVm4Ha7cHs8eNxufD4fPp8Xj8eFrkskYucR02BssCwby4pP WzQMMEyIRix6g/0MBAcI9vcxOBiivz9IKBSiN9BFV9dR+vraGBwIjmi/p6oqeXl5FBQUcM45 5zBr1iy8Xm/y/kTGXATQwngTAbQwJgG0ZdlEIxaDAwaBrij9fTEiEYt4n2kbOL39f7wAOr4y TPXMAi68sJpp09I/8XEFYaxYlkUsGuWnT73Cc2/Xfui2i6pLue3qdeJja+ETCwaDNDY20tjY yJEjR6irq6O9vf247eKdeRxomo7D6cDhcOLQHaiqgm2Doqj4/T5kJT7BL9HswzBM+oJ9mIaJ Tbw0KRwOEYlEiUbDmGaUcDgKHP8JZX5+PgUFBZSWllJcXExBQQE+n++EP4cIoIWJIq6+wpiQ ZQmnS8HpUkhJ0zANCPRE6OuOMThgEAlZSEMXOdu2scdswRYZj1dlyZIKVq6sxO0+M/s6C1Nf /I2syZv7G467T5EkzGFvON/YV8e9T77CLRvXnNUTX4VPzufzMXPmTGbOnEk0GiUUCjEwMEBj YyN1dXXU1dXR1dWFaZrEYjEikRD9/X2n/SlioiWgoij4/V4URSEzM5Py8nJKSkooKCjA6/Xi dDrRdXG9FiYvEUALY05RZBQFsnNdZOe6GBw06AtEGQiaBANRYkY8i2Fhg2lhj0q/0nj2obwi k9WrZ1BdnTsK+xSEsZH4FGhvXTM9/aHj7p+V52Vnc3DEbc++sYcMv4crzl8ogmjhtOh6PHOb kpJCfn4+ixYtAuKfigQCAXp6eggEAnR1dREIBOjr6yMajSa3CYVCJ+ze43K5ks9NVVXJyMgg JSWFtLQ0UlJSyMzMxO/3i+evMCWJAFoYd263itutxstGwi4G+g0CPTEGgzHCIRtJVoaK6j5p mYeEx6uzZEk5y5dX4PU6R/tHEIRRZds2lmny2u5DJ7xfAorSXDT2jAyuH3r+TdL9Xj61YKYI QoRRJ8sy6enppKd/eNmbZVkjaqkTjxXPSeFMJgJoYcLIsozTLeN0q6Rm6MSiFn29MYK9Bv19 MWJRwJaRJQnLsk6hm0c861xamsGa82cwY0auuIALU0J8AmGMt2obR9yuKjKGadHWH2VuYQpR w6ItGBmxzT2/e5k0n4cFM0pE3acwIUSwLJyNxDNemBQURcbpUsnOdVE63UtFtY9p5R5S0xVU HbAtNFWPZ6dPSEZ3KCxeXMLV1yxm5sx8cUEXpoRE+cauumZ6B8Ij7sv0xHMcXf1RsnxOXJpC VY53xDamafGDXz/LwcbWUetyIwiCIHw4EWEIk44sS3i8Gtm5TkorfVTN8lNc6cOfKaM74rV1 sixh22BbNiBTVJTKX/3VQi7dOI+UFPdE/wiCcMoS5Rtbdx8ecbumSJSmx5/LMctGUVSCEZNP zchiWpprxLbhaIzv/PIPNHcGRBAtCIIwDkQALUxqqirjdCtk5zopKfcwvdpHyXQPqZkaqiaj qDIL5hdx9TWLOeecQrGioDDl2LZNzIjxVu3I7htlGW7yUo4Fyl2DJpl+J/1RuPScfLK8jhHb 9/aHuOux54fKnUQQLQiCMJZEDbQwZSiKjNsr4/ZqZGRbpGdqpOfOJjfPi8sl2h0JU0+ifGPn oSb6Q9ER983I8ZGfdqxco7UvRH6ql96oTX6ai8vmFvLrt47QFz626MSBo+0YsRiaWGRFEARh TIkMtDAlybJMSpqD0rJ0ETwLU1aifGPLB8o3HKpCZX46fo+TtKHe5c2BQfIzU+gaNPB4fWSk eLh8XhHOYZ+6zJ6WQywWE1loQRCEMSYy0IIgCBPEtm2isSjvHBzZfaMyx4fH7UZWZPJTPfQM RmkNDJCf7uPt99vx+nzIsky+JHHNomJ2He3F73Vx4dwZxKIRdF1HUUQ5kyAIwlgRAbQwQp5u EpMMkcEShDFm2zaGbdDQH2AgHBtx35LiNAp88SWJK7M97GnuwbBsPMQYCIXJdatYupt+zSJN MalI1XE4HKTpBhlyFJ8SRVcQnWiEM158UrmMpomSJWF8iQBaSEpciBIvuiKAFoSxk3iTmurW mZbhpaGrH4Bsr855JVm43W4kSaI8JxVoAqC+q59pmX5a+iJU5qWh6zqaphGNRlEUBZfLhaZp yaWSRR20cKYb/rolnu/CeBIBtAAcuwipavwpYdufdBVAQRBORWL1NlmW+X/rz+Opdw4RMwwu mJFHit9PSkoKtm0zo+BYdvpIVz/FmX6O9gywoKoYj8eDx+MhFoshyzIulwu3243T6RQBhXBW kCQJSZJQVVU854VxJQJoIXnBURQFXddRVVUEz4IwxizLQpIkIpEIWak+Ns8vxTRNvF4vaWlp +P3+ZJY6N8VNa+8gdZ39LJtZwoHWXrxeL4qiYJompmkmg4hEBloEEsLZIpEASnzqIp77wngQ AbQAHLsASZIkgmdBGAeJADoWi5GSkoIsy1iWlQygPR4PhmEQjUapyEmhtXeQxq4gRZkpPLvj CLoer3tO/M0mAgeRhRPORonnv3juC+NFBNBCUuLiIwJoQRh7iRd6j8eDbdu4XK7k/z0eD7qu E41GcTgcTM9L57UDLZiWTThq0N0fYjASxeVyHVfrLAIIYbJJvMH7MIZh0NLSQjAYJCsri8zM zI/1XBbPe2G8iQBaOM5oXYhisRhtbW309vaSnp5OZmYmmqaN2Oa+++6jpaWFb37zm6NyTEGY KhJ/Z4l6Zbc7vmx3ogwjkZHWNI2q/Izk4w40d1GancqBpg6WpKaIjLMwadm2ze23305PTw+f //znmTt37gm3279/P7/+9a/p6elJ3qaqKps2bWLlypXjNVxB+FhEAC2MutbWVh555BHq6uqw LCt5uyRJpKSksGnTJubNmwdAMBgccdEE+NGPfkRjYyP//u//Pq7jFoTxlgh+ZVlOfvIz/GNo RVFQVZWqgszkp0MHWropy0lnf1M7i2aWnVJ2TxAmwr59+5LX923btp0wgO7o6OCnP/0pfr+f G264gYqKCnp6eti7dy8ul+u47QVhshABtDCq3nrrLX7961/jcDj47Gc/S2lpKSkpKQQCAZqa mti/fz+GYXzoPkpKSvB6vR+6zWgIh8Ps2bOHjIwMSkpKxvx4gnAiiQD6g7fZtp3sjON1OylM 99LYFeRgSzerZ5eys7FDdMsRJrWtW7fidrtxu93U1tbS09NDWlraiG127txJNBpl/fr1ycSK 3++nuLh4IoYsCKdMBNDCqA31eUkAACAASURBVAkEAjz66KO4XC5uu+02/H5/8j6v10thYSGL Fy/+yP1s3LhxLIeZ1NnZyf3338+FF14oAmhhQp0sgzy8s0Z5TgqNXUEaOoPkpXn53zdqk5/w iCy0MNn09fWxe/duli1bRmpqKk8++STbtm1j/fr1I7ZLBNR1dXXU1NRMxFAF4RMRAbQwap5+ +mkikQgbNmwYETx/XI888gjt7e387d/+7Yjba2trefbZZ2lqaiItLY0VK1awYsWKkz5269at vPnmmzQ3N1NeXs5f//Vf4/P5ANi9ezdPPfUUAG+++SYHDx4E4Ktf/apYvU2YFIa35lJVlYqc NF7e24Rl2/QNhOgbjNDbP4iu6+I5K0w6r7/+OqZpsnTpUvx+P08//TSvv/4669atG/Fmb86c OTgcDv7yl78Qi8X47Gc/i67rEzhyQTg14qorjJrGxkaAk04UOVWtra0cOXJkxG3bt2/nnnvu IRaLsX79elwuF4899hivvfbaCR/7pz/9iccffxyXy0VOTg67d+/mpZdeSm7n9XrJz88HICUl hbKyMsrKyk5r3IIw2iRJQlGUoYmE6cnb9x/tojQnldqmdlHCIUxK27Zto7i4mIKCAnw+H7Nn z6anp4d9+/aN2E7TNG666SacTievv/463//+99m9e/cEjVoQTp0IoIVR09HRgaqqySzvaInF YjzxxBPk5OTwta99jTVr1vDVr36V7Oxsnn/++eMCiGg0yquvvso3v/lNvvCFL3Drrbfi9/t5 9913k9uUlJRwwQUXAFBVVcWmTZvYtGmTyOQJk06iDnp6QSbK0PMz0YmjtrE9udiKIEwWtbW1 dHZ2snTp0uRtiX9v27btuO2rqqr4p3/6J2bMmEFXVxf33nsvDz300IhJ6IIw2YhoQRgV0WiU aDSK2+0e9VrMAwcO0Nvby3nnnTfi9oqKCrq7u+nt7R1xuyzL3HLLLWRkHGv9lZ+fT2dnJ7FY DEGYKhJlHKqq4nE6KEz3AHCwtYeSLD+1R8VEQmHy2bJlC7quU11dzeDgIIODg0ybNg2/38+u Xbvo7+8/7jFpaWl86Utf4tprr8XhcPD666/z2GOPTcDoBeHUiBpoYVTouo7H4yEYDGIYBqo6 ek+tjo4OAF588UVeffXV5O2JYLinp4fU1NTk7aqqUlBQMGIfH+w/LQhTxciJhKkc6QzS1N1P jt/NoeYuMZFQmFT6+/vZuXMnpmnyz//8zyfc5o033kh+AvhBNTU1FBUV8YMf/IB33nmHyy+/ fFRfTwRhtIhnpTBqMjMzOXLkCO3t7cn64tFgmiYQv7B+MDAGjmuLJAhnig9OJJyem8aLexqx bZuegRD9oQjdfQPkiomEwiSRmDy4efPmEYkNgEgkwq9//Wu2bdt20gAaIDc3l8rKSvbs2UND Q4OYnyJMSiKAFkZNWVkZR44c4aWXXuKqq64atf3m5uYC8cl+y5cvH7X9CsJUkAiiNU2jquBY WdL+pk7Kc9PY39hGTkbqh+xBEMbPtm3byM3NZc2aNSe8/6233uLAgQMcPnyY8vLyE35yYts2 bW1tQDwxIwiTkUhZCKNm7dq1uFwu3nzzTfbs2XPS7QYGBj7WfsvKyvB6vWzdupVoNHq6w0zy eOL1pJ2dnaO2T0EYC4k66Iq8DBQ5HmwcbOmhNCeVA0c7xERCYVI4ePAg7e3tLFmy5KTbJO5L TCZ87LHHuP/++9m1axddXV3U19fz6KOP0tnZybx5806rJaogjCWRgRZGjcfjYfPmzTzyyCPc e++9LFu2jFmzZpGVlUUgEKCxsZGtW7eyfPlyzj///FPer8vlYuPGjTz44IPcddddXHTRRWRl ZdHW1kZ9fT2LFi0iKyvrY483LS2NadOmsX//ft59912mTZs2YuKhIEwGwycSup0OpmX4qOvo 42BrD5+ZP5136trFREJhUti6dSuqqrJw4cKTbnPuuefidrt59913ufzyy/H7/bzzzju88847 yW0URWHFihXjtqiWIHwSIoAWRtXixYspLCzkkUceYcuWLSP6NCuKwuzZs6mqqvrY+120aBFe r5fHH3+c//7v/07uLycn57RWr7rooot48skn+fnPf44sy9x1112feF+CMFaGTySsyEmlrqOP 5p5+sv1uDhztTGagxURCYSJdd911XHfddR+6jaZp3HHHHcnv161bx7p16wgEArS2tuJ0OsnJ ycHlco31cAXhtEi2SFsIYyQWi9Ha2kowGCQ1NZWMjAwcDsdp77e/v5+BgQGysrJGbeJUZ2cn brcbt9s9KvsThNFkmiahUIiuri4eeuFt7nn+PQDuuHoN9720i1/eeiW5mWmoqioCaEEQhHEg MtDCmNE0jaKiolHfr9frxev1juo+xUQVYTIbXsYxfEXC2qPxiYT7xERCQRCEcSUmEQqCIEwB iQC6PC8DTUmsSNhNmViRUBAEYdyJAFoQBGGSG56Bdjp0ijN9ABxq7aE4K0V04hAEQRhnIoAW BEGYAhIBdGJFQoDW3kEyPE4ONo+cSCgIgiCMLRFAC4IgTHKSJCFJUnJFwsq8Y3XQ7b39WJZN R6BfBM+CIAjjRATQgiAIU0AigNY0jenDAuja5i7KhlYkFAG0IAjC+BABtCAIwhSRXJEwPwM9 OZGwi5KsFPY3tok6aEEQhHEiAmhBEIQpYHgZh65plGSnAHCwtYeSLP+IOmhBEARhbIkAWhAE YYoYPpGwIiceQHf0hUgXEwkFQRDGlQigBUEQpoDhGegP1kE3dweRJYm2nqAIngVBEMaBCKAF QRCmiOGdOKryM5K3J1ckbGgVAbQgCMI4EAG0IAjCFDF8QZXSnDScmgrAgZZuSrJSxYIqgiAI 40Sd6AEIgiAIp06SJFRVRdd1SrP81Hf2oasKK6qL6ImIGmhBEITxINniSisIgjAl2LaNaZoM Dg7S2dlJfVMLmmThdDrx+/2kpqbi8/nQdR1FUZAkaaKHLAiCcEYSJRyCIAhTxPCJhA6Hg8xU Hw6HA03T0DQNWZaT2wmCIAhjR5RwCIIgTCGJEg6n04nPFw+gVVXF7XbjcDhE5lkQBGEciABa EARhCklkoF0uF7IsYxhGfHEVXUfTNFRVTWaqBUEQhLEhaqAFQRCmGNu2sSwL0zSxbTvZnUOW ZRE8C4IgjAMRQAuCIExBiUt3IoAGUfssCIIwXkQALQiCIAiCIAgfg3zoTz8hHGib6HEIgiCM qdtvv53Vq1dz5513EovFRK/ks9iXvvQlVqxYwS9+8QvxXBAE4RNRjz7+XXbc/39JLT+PwoWf pWDRJrzZJRM9LkEQzjJf+cpXeOONN04pmMnKyuKJJ57A4XCcctnC4cOHeeWVV0hPT2fdunVU Vlai6/rpDluYgg4dOsRrr73G9OnTWbZsGaWlpWiaNtHDEgRhClGP7DPpiHgpaD+A1vKf7H38 n3HnFFC4+FoKF20ipbB6oscoCMJZIBKJEAgEMAwDiNf2trS0EIlEKCwsHBHgmKbJm2++ycKF C3E6nae0f8uyAOjr66Ozs5OKiorR/yHOAsFgkB07duD3+5kzZ86Y1V339fWxc+dOUlJSmD17 9qgeJ/EmLRAI0NXVRXFx8ajtWxCEs4NqA5kOjZY+E+OAiYSPwaOd2C33cOgPd6K4/RQtvYqi RZtJK58vJqkIgjAm7rzzTt58802ampqSq+1973vfo729nUsuuYTZs2cng2hd14lGo5/oOJZl JYNp4eP71re+xV133cX69et54IEHSE1NTS7gMpr+8R//kXvuuYdLLrmE+++/n5SUlFE/jngu CILwSamyBDYgS4kvGctwcOiQQbbLA0qI3v4HaHj+f7A0lcLFV1K4aBNZ1cuRFdFGWhCE0eH3 +1m2bBmhUAjLsmhoaMDlcgHxgHnhwoUUFhYmW7Vpmoau63R1dfHCCy/w6quv0tfXR35+PuvW rWPJkiUfWaJhWRYPPfQQzc3NrFu3jurq6mSQ/sYbb/D73/+ehoYGfD4f1113HQsXLkwGcZFI hJ/+9KfEYjFuvPFG3nnnHZ566in6+vqYM2cON998M06nM5l0iMViPP/88/z5z3+ms7OT9PR0 ampq+NznPoeqfvxraXNzMw8//DA5OTmsXr2aP/zhD7z99tvYts3q1au58sork/uNRqP8/Oc/ JxgMcv311/PSSy/x0ksvUVxczK233oqqqgQCAV588UVefvllent7yc3N5TOf+QzLli3D4XAA 8NRTT3HgwAEgXgbxjW98g6KiIr7yla/g9XqRJInDhw/z29/+ll27diHLMmvWrOHKK688rkSi tbWVF198ka1bt9Lb24vf72fGjBncdNNNPPfccxw6dAiA2tpavvGNbzBt2jS+/OUv4/F4kCSJ gwcP8rvf/Y7du3cjyzKf+tSnTngujxw5wqOPPsrevXtJTU1l06ZNouZZEITTd/+yfPtXy/Pt B1fk23ctyrEfWJFvP7KqwH50dYH9X4tz7EdXF9i/WVNgP3F+of2TFZn2i3+db//xpmz7f6/1 21v/9XL76Nt/sI1IyBYEQThdlmUlvw4fPmyXlJTYgP3Vr37V3rNnjx2NRkds09PTY1988cW2 qqq2LMu22+22Advv99vXXnut3dfXZ1uWZdu2bV955ZU2YK9Zs8Z+4YUX7N7eXvu2226zZVm2 zzvvPPv555+3e3p6bMMw7F/+8pd2UVGRDdgul8sG7PT0dPtnP/uZHYlEbNu27draWjs7O9tO T0+3161bZ6emptrE8xG2pmn29ddfnzx+JBKxL7/8ctvlctmSJCXHOX36dHv79u12LBb72Ofq gQcesAF79uzZ9nnnnZc8NmA7nU77+9//vt3b22tblmXX19fbxcXFttPptGtqamxd123Arqmp sffu3Wt3dXXZmzZtsjVNG3EefT6ffcUVVyT3s2rVqhHHAWyHw2H/7ne/s0OhkL179257wYIF I86b0+m0//Vf/9UOBoPJ38WBAwfslStX2pIkJfeReMzvf/97e+nSpccdJ3FfKBSyd+zYYc+f P3/EcVwul/2DH/zA7u/vTx5n165d9rnnnmsDtq7rtqqqdkpKSvJ5demll9qvvfaaHQ6HR+kZ LAjC2ULZOM33bUWJX6FCpo1blZElCUmCQcPCo8rIEiDBQExCDivYAQVlUKGvvZ5A7R/Y+Zvv EKh/D8u08WROQ9EcYx/5C4JwxkksAiJJEoFAgF/+8pcEAgGWLFnCvHnzyMzMTC5VHYlE2LBh A3/6058oKipi8+bNbNiwAYfDQX19PTt37sSyLBYvXoymaTzxxBPs3r2b0tJSli9fztNPP80d d9xBQUEB11xzDRkZGWRnZ3PgwAGuvvpqIpEI69at44orrkCWZfbt28fBgwdZuHAhOTk5BAIB fvWrX9Hb20t9fT2lpaVcfvnlOJ1O6urqaG1tpby8nPLycmpra/ne976HZVlcfvnlbNq0iZqa GrxeL4WFheTn53+sCZEAO3fu5Le//S19fX0Eg0EuvvhiVq1axeDgIC0tLbz55puUlpYyY8YM BgYGePDBB+nq6qKzs5O5c+eyYcMGCgsLyczM5B/+4R94+umnKSws5JJLLuHSSy/F7XbT0NDA zp07iUQiLFu2jFmzZnHo0CGOHDlCRUUFmzdvpqamhry8PDRNY/PmzezZs4cFCxbwhS98gaKi Ig4cOMC2bduYMWMG5eXlBAIBLrroIt566y3y8vI477zzuP7661m8eDFer5fi4mIuuOACmpqa aGxspLKykk2bNrFgwYLkcTZt2sS+ffuoqanh5ptvprCwkNraWt544w1mzpxJWVkZwWCQz3/+ 87z++utMnz6dG2+8kZUrVxKJRNi/fz+maVJVVcWyZcvIz8//RJ8CCIJw9lK7oybZTgUbyHKo dEYMclwqlg05LpX2sEmOU8G0Idup0hE1yHGqmJaKPgCNe01y3an0bfkLoYNbeeue68matZKi xZ8jf8HFOFOyJ/pnFAThDFRbW8vu3btRVZWLLrqI5cuXM23aND73uc9xyy238MILL/D73/+e Sy65hHnz5o147EsvvcS9996Lz+fjs5/9LBUVFVRVVZGRkcG//du/0d3dzeLFi7nkkksoKiri wgsv5LLLLuPw4cNs27aNqqqqZBlANBpl3rx53HjjjRQUFLB69Wr27NlDT08PdXV19Pb2Eo1G CQaDqKpKZmYmq1atoqCggGg0SjgcRtf1Tzy/xO/3c+211zJ37lxyc3PZtGkTX/ziF6mrq+N/ //d/WblyZXKslmUlx5qTk0NOTg4tLS3s3r0bRVFYu3Ytq1evpqioiCuvvJIvf/nLPPvsszz9 9NNs3LiR+fPnM3PmTF599VX8fj8XXnghZWVluFwudu/ezfvvv09ZWRlXXXUV5eXlXHbZZeza tYvt27fz1FNPsXjxYrZv386+ffuSxzv//PPJzc2ltLQUwzDo7e1l+vTp/OEPf2DLli2kpKQk j+N0Onnvvfeoq6ujvLycq666irKyMi677DJ27NjBjh07eOqpp1i4cCG7d+9my5YtZGVlcc01 1zBz5kymT5/OVVddxWWXXcbevXtP7wkoCMJZTYV49lmRwLBtEpdwRQLTAol4VkgFLGwkO36b LksYQxdlyVawBxTC70Mokkok9B4NTXt59xdfJq10JoWLr6Wg5lI82WKmsyAIo2PHjh10dnZS UFCQzLRWVlbidDr54he/yAsvvEBHRwe7d++muvpYN6FQKMR9991HNBrliiuu4Nxzz6W6upqi oiI0TWPPnj0AtLS0cO+995Kenp5cKjsajXLw4EECgUBy8pnX6+Xiiy+mpKSEefPmEQwGSU1N JRgMEg6HiUajyTHu2bOHBx98kObmZr70pS9RU1ODqqqn1ULN5/NRVVXFOeecQ2lpKaqqUlNT Q11dHU1NTRw9epTs7HgiQ9d1Vq9eTWFhIfPnz8fn8/H+++/T0tJCbm4u5eXlVFZWUl1djdPp 5Ctf+QrPPvss7e3t7Nmzh9mzZyfr0iVJwuv1UllZicvl4uc//zmmadLf389DDz1Eeno6DoeD SCQCxGuRW1tb2bJlC4ZhUFhYyKxZs6iqqqK6uhq3251colxVVTweT/I4Pp8veZyf/OQnWJZF MBjkwQcfJD09HV3XicViANTX19PS0sJf/vIXIpEIWVlZFBYWcu6551JUVISiKOTl5bF3714x KV4QhE9MzXYqdEVN0h0KuiyR7VJpDxtkOlRUGbKdCu1hgyyngiIN3R8xyRzaPm9o+2yXiqZA jlujPWCSFZZIlTOJ9jXS2vwD9jz6Ddw5pRQNTUL0F86Y6J9dEIQprLOzE4gHhWlpaeTl5eFy uZBlmdLSUhRFIRwO093dTSgUSj5ux44dhEIhKioqmDFjBtOnT6e8vDw5UW5wcBCA7u5u+vr6 kpMWbdsmLS2NwcFBgsEgiqIAIMsyDocjmcGORCLJMpREQJidnc3PfvYzbrrpJvbt28fjjz/O Cy+8wAUXXMB99913WgG0LMs4nU5yc3Nxu91IkkRqaioAhmHQ399PVlZWcntN0ygrKyM1NRVV Venu7h5xHvPz85PnsaCgAJfLNeI8Dg86E5M5NU2jp6cHiLefO3z4MHV1dSPOWyQSoa+vL7md w+EgKyuLoqIiPB7PcR02TuU4hw4dOu73Ew6HCQaDNDc3J3/etLQ0srKykpn+segaIgjC2UW1 AdsGhXhGWZMkJECVwbLj/0cCRZLi30vx7dWhjLUqSckuHoYFmhy/6ClyfHuH5eToEYM8VzqR njYCff/NwSf/DdWXRtGSqyhcvJm0snkiEyAIwsfi8/mAeDcM0zRHlEG0t7cnbwOSvaUB5s2b R0NDA4cOHeIXv/hFsstE4rGJvtJz587l05/+9Ij7LMsiNzf3uLEkguhEUP1BkiRRU1PDww8/ zCOPPMJTTz3F7t27+e1vf0t1dTVf//rXk8HvJyHL8ohj9/X1AeByuU7Ypk3TtOSxUlJSgHgp imEYI85jIBAgFAolA3LTNE86hsR+CgsLueaaa3C5XCPOW6LdXWK7RMZ4+HanIjGWoqIirrrq qpMeJ3E+YrFYMsuf2M4WXTgEQThNqixBhkOhM2KQ7YxPosh0HKt9BoksPZ6FznWpIA1lpSMm uU4VSYJcl0pHyCTHrWBjk+1SaA8Z5LlUJCDXqdIWMsl3u7BaId1Oo7V9kMHwr9j68v9gopAy 62JmXngdmTOWI5/kRUgQBCHhnHPOwev10tXVRX19PYZhYNs2kiTx4osvApCWlnZc/2Bd17nl llu4++67ee+997j11lv5yU9+QkVFBbIsM3v2bF588UWOHDnC9OnTqampSWangWQQ2NDQ8LHG qygK1dXV3HrrrWzcuJHLLruMhoYGXnnlFa644goqKyvp7++nq6sLr9d7wkD9RD4YDPb29nL4 8GGAZCb+w1RVVZGWlkZXVxeHDx8ecR7//Oc/A5CRkZE8j4kgdPibEoBly5Zx991309nZiaIo yYmIie0lScLtdhMMBvnxj39MS0sLL774IuvXr08e70QSgfbw49xzzz10dHSg6zobN24cEURL koTH4+GNN94A4m8COjs7k28k2tra6O3t/fCTKgiC8BGSryqJa5c09O9E7fPwS5qd/E88Cy1J 8a/hl295xMduDH20NmwfQ/+WLR26VLK6/KR1aphvPcM7d3+W392Yzht338Du5x8gGOgexR9V EIQzyYwZM1i6dCmRSIRf/vKXvPTSSzQ1NXHnnXfy2GOPoSgKM2bMICsra0QADDB//ny+/e1v k5mZySuvvMLf//3f09jYiGVZXH311RQUFNDQ0MB//ud/0tTURDQapaenh0ceeYT29vaPPemv traWK664gq1btxIMBjFNk/T0dCCe1U1kzG+44QbOP/98Lr30UsLh8CllSpubm3n00Uc5cOAA R44c4eabb2b79u0UFBQwe/bsj1zoJNGJIhaL8fDDD/P888/T0NDAj370Ix566CEkSaKiooLs 7GwcDgdFRUUANDY2sm/fPpqamrBtmxUrVrBw4UJ6enr46U9/yjvvvEMkEiEYDPLqq6/y8ssv 4/F4WLp0KYsWLSIWi/Hcc8/xq1/9ir1797J9+3b+7u/+jrq6OizLYtq0aQA0NDSwf//+5HFW rVpFTU0N3d3d/OQnP2H79u3J8pCXX36Z1157Dbfbzfnnn092djbNzc38x3/8B6+88goPPvgg GzZsYOfOnaf8uxMEQTgR1bLj5RlZDpWOiEGWQ0UZXvvsUFBkidyh2ucsh4I2VPvcGop35JBl hrLOJtkuBVWSyHOrtAzdr8gS+W6V1rBB7tD3BS6N1lA86+2UdVwhaOk2yHM7kN/+Ey37n2P/ /V/AUbyIJjOPmRdcxcIV5ycnsAiCcOb7sFXiUlJSuPPOO9m1axfNzc3cfPPNZGRk0NzcjGma rFixgvXr15OVlYXb7U6WHyQmqf3VX/0VoVCI22+/nWeeeYavfe1r3H333cydO5fbbruN22+/ nddff52LL76YzMxMAoEA3d3d/PCHPyQ/Pz+5it3Jgtzhtzc1NfH444/z5JNPkp+fT19fH11d XZSWlrJx40aAZGu+xsZGdF3ntddeY/ny5R+5VLnT6eS5555jy5YtuN1umpqa8Hg8rF+/nunT p5Ofn49hGCctv/B6vdx55528++67HD16lL/5m78hKyuL5uZmDMNg4cKFXHrppcnzuHbtWsrK ynj//ff5l3/5F3784x/zxBNPcM4553D33Xdz6aWXUl9fzw033EBeXh6hUIjW1lauuOKKZMu4 u+66i0suuYSjR4/y9a9/nTvuuCM56XLevHls2LCBtWvX8l//9V/U19fzne98J3mc2bNn86Mf /YjLLruM999/n+uuu27Eca688koWL15MdXU1V199NXfffTe7du1iw4YN2LZNfn4+OTk5NDQ0 fGhJiiAIwodRNhf7vq3Kx/o+u4f6PkvAoGHjUWWUobrmxPeyJCFL0G9YeFUZRY5nngcNC482 1EcaCBoWPk1Gloe+j8W/l6T49v1DfaYVOZ6t7jcsUjQVxVDxDaoMBnWyo92k6k30vPUgh7b9 hl/87H7e3vs+suokOztb9O4UhDOUpmnU1dWRkZHBvHnzqKysJD09fUQ2NdESbmBgAMMw0DSN 0tJSLrroIlavXk1paSlz587F4/EQCARQVZXy8nJmz55NcXExNTU15OfnEwwGiUajyXZqCxYs oKqqisHBQWzbTmZe16xZw5w5c0hJSSEvL4/Gxkb8fj/z58+nsrISn8+HruvU1dXh8/moqamh qqqKOXPm4Pf7CQaDycluS5YsYcOGDVRUVHDuuecmy0L27t2LpmmsXLmSioqKk04wTPSBLigo YPPmzUSjUVRVpaqqio0bN7Jw4UJmzJhBSUkJHo+HhoYGPB5Pckx+vz95LtPT01mzZg2hUIhY LIamaZSUlPCZz3yGtWvXUlpayrx58/B6vWRkZFBdXU1dXR2appGZmUl1dTW5ubmUlJSwatWq 5GqSmqaRlZXFsmXLWLFiBS6Xi7y8PPLz81m2bBnBYDBZclFWVsaqVauorKwkKyuLsrIyKisr aWhoSLb/q6qqSv6OVqxYQTgcTh4nOzubZcuWsXz5clwuF4WFhaxatYq+vj4GBgbIzMxk9uzZ bN68GZ/PR3Z2NrNmzWLWrFnk5eWJ1xJBED4W6a6FOXaOS8UkPoEwUetsEZ8Q2Db0vU283qMj Yg59H59A2BIyKPComFa8oLo9bJDvUjGHHt8SMihwq8kJiS0hg3y3hmXbx+4ferymSDQPxijy aJg2aAocHTAo8moYtomhmYTTNLoH+7BTivjN1mb6fRXUrLiQ1SuWM29BDU6vDyQxw1oQzgSD g4Ps2rWLSCRCVVUVWVlZx5UjmKaZrIPu6enBNE1UVSUrK4vi4uJkCUMsFksucJKZmcn06dPR NI1IJMLRo0c5cuQIz0Qn4wAAIABJREFUTqeTyspK0tLSiMVitLW10djYmAx8FUUhJSWFqqoq UlJSiEajbN++nWg0ynnnnYff70eSpOS4o9FosowiEolQW1tLR0cHsVgsGTiWlpaSm5uLqqrU 19ezZs0aFEXhhz/8IZ/+9Kdxu90nPDcPPfQQV199NdOnT+db3/oW1dXVyVpfXdcpKCiguLg4 WR8ciUR47733iEajyTcBw8tQTNOku7ub+vp6uru7k+cxMzOT4uJi0tLSkuc+FovR0tLCgQMH iEajOJ1O5s+fj9/vx7Isurq6OHLkSHI/iqLg8/koLi4mNzcXRVEwDIPOzk7q6+uTbQE1TSM1 NZUZM2bg9XoxDIOjR49y6NCh5HEWLFiAz+dL/t6PHDmS/L0njlNSUkJubm7yd1FbW0trayu2 beN2u8nNzSUcDtPX10dBQQElJSUigBYE4WORfrwox84emgxo2dAdjU8elCQJy7bpjsYDZgAL 6IqY5LuPfd8djk8elJAwbZvuoQBblsCwoTNiUjC0vW1DR9SgwK0hEe/i0Rk2KfCoSJKEadm0 hw0KPRrSUB/q9rBBoVcberxNW8ikwKcQlgwi2S66B4JY7kx+/04XL+ztouLcpaxZvpTVy5Yy b95cHF4/6E6QxcREQZhqbNsmGo0CoKrqSSfEWZY1okxBkiQURUFV1RGdF0zTxDRNZFkecZ9p msmgdvhxTNPEMIxkKUmiBZqqqsiyPGJ8mqYlA8wT3W7bdnKMifKOxL4Sx5s7dy5tbW3ccMMN LF26lPPPP3nZ2vAA+tvf/jYXXnghHo8nGfhqmpZctfFkY/ok5zEhcc4SEwB1XU/u84P7OdHP erLjybI8omPG6R7Htm1isdiIY6iqmiy/Sfx8giAIH4ea7YzXPif6Puc4FToiJplOBVWWyHaq tIXjfZ81GfJcx2qbVRly3PHa50znsb7QreH4aoa6IlEwVAud7UzUTmscHYyR61TRFIl8j0rz YHx/mipR6NFoHjTIdatoKhR6NZqHtlcViUKvSlN/PIvtbTfJwEVDTw9fXJjCFXMdGHI773e8 zjV/fQdH+xVWLl/KmiWLWb2khrnnnoPD68fWHEi6ExTt2OxJQRAmHUmSjpsAeCKyLCdb1n3Y vlRVPWGwpCjKCYPzk93+UeM70e3DexmfzHe/+11aW1tJS0ujqKjoQwM7h8NBfn4+siwng8bh i5yc6liHO5XzmPBh5+ZU93Mq253ucRJBtyAIwmhKXp2VoQy0MtRVQxnKKKtDF2JdifeJHmoL ncwwaxKYdrx8wxgqy0iUe5iWnayf1hQJy4rvX5akY98rQ32llXgGWlak5MqIpgmKbGNboKrH Hi8N7c+0bFRFQorJpLRF8SETUwbJ8TYz6/oKIgb0etP47n3/wTe+F8HhcLJ6xTJWLVnImoXz OW/mDHS3F1t3IGlO0BygO0QJiCAIE2Lt2rUcPXoUSZI+co7HJZdcQl5eHrW1taSmpiaDTNFT XxAEYexJj64usG07XpqR7VKQiAfQXRGTXHe8j7NlQ2fUJH+olAMJOsImuS4lmcDtCJvxvs9D C620D5V6JB7fEYlnjWXAlqAtZJDvjpd62MS/L/Royf23DBgU+lQk4itMtYZMirxqcnwtg8NK OyRoHogxzTfs+0GDHJ9KLMVBwKUSHowS9M3gjgf+zDsN/cQscDmdrFm5nDVLF7GqZh7nzojX REqqjp0IprWh4Fr95CuFCYIgnKpEqcFH9W+GeC1yT08PmqYd1+9aEARBGDvH0hvDej9j2yMq G4aSyNg2yEMrFEKiX7SEjR1/7NDXsF3GHy8Pq5SQjvWCPlGiJBGAJ/YtDd2Y7FM9tGTr8P3H tz/WyDrRr1pHQgtEcAUiHA2ZVEuHuPvzsxjoizDoy+E/H32bl156kT/+Kb5YgNvlYs2qFaxe vJA1i+ZxTtV0VDU+gVKSlaEM9bBMteb4wE8sCIJwek4lcE5IdMFILB0uCP+fvTcPk+sozPXf OksvM90zPdpnpmeRLNmyhGxL1i7bGrGHJZgELiELJNw8YUkgIXmSG0gIuYEfgUsgBJIQEofF GBuMF2xjG+MYg8EYrxgs77as2We0zT69nKV+f1TVOadHspFteT/f88hS9antnG5ZNV9/9Vaq VKmeHYmLdndKWx+IcrAasDRnYwuBZcGBquI+OxpTN6aJHAZzd6ASbyC0BYxVFdfZ1Vi8sYqq b+sDVQzRw9b/nx+r+LQ3OVhCtR+e09lnW81ndE5dty2FzRueU8QOEwsZmvPobHaxLKLrK5pV NlsIweCcR2eTg2Wp+xmY8SgXXbDAa8oxV2phtlKnVuzi3y+/jRvuHWOqGm9GaWpq4hW7z2bP jm3s3rqJ005ZveAfNwFupmFhLdINi6lSpXqB6vrrr+dTn/oU5XKZL33pS2QyGUZHR3nb295G a2srl1566eNuQEyVKlWql5Ick2cGIj6zMDmJhBMdnQkgUW61iN1iR/+/VEC0OF7ohUgkUqr6 UsRjmnHN77ZlnOz4WFZLxK63mYsl4naWUEQQmbgXMwFhHe10WxLylSqHDs5SLjgE1Sr/8NaT +MvXdFNvXsZXrtvLNT8f5MDMPFddex1XXXsdAIXmZl6++xz6dmzh5VvPZP3JJ2EjwavB/HT0 eLAdtZB2s+DmlFudblhMlepFrZtvvpl3v/vd2LbNRRddxNq1a49aaF5wwQV87nOfi9xiy7LI ZrMsXbqUP/zDP+TVr341tm3zr//6r3zta1+jXC7zzW9+80mffPhU9dhjj3HDDTdwxhlncPfd d7Nx40bGxsa44447WLJkCbfeeisbN26kUCikjneqVKle0nIO1RQxI5Tx6YMrNMe5vclhrBLQ 3qS4z+15h/GKcomDMD59sKNJ1V+hTyfsbHYJpKSjSRE2ys2K+2yIHJ3NDmFIfL3g4ktJZ7Oj uc8OQSjpLLgMz6psswS6Ci5Dcx5dBdV/udllcM6jp+ASSigXHAZnfbpbHPxA0lVwGdTt/VDS 3eIyMOvRU3QJQugqOgzO+PTYVdzHRijZMHTwCP/n9WXe9/IyfqaVi27ax3dufYTBiSqzc3Nc ec21XHnNtQAUCwVesfsc+nZuZc+WTaw/+ST1D2bgIyuzUJmNn7QQjQtqN4dwsyrfkipVqhe0 fN/ns5/9LPfeey8AH/nIR/j3f//3o7jVBw4c4M4776RYLLJ48WKCIODgwYNUq1W+//3v87GP fYz3vve9HDx4kDvuuIN6vc7tt9/Oli1bjotG8nRl4nHVapWDBw9GyD2D4BsdHWXt2rU0Nzen C+hUqVK9pOWYnLGtucsmx2wL8IzbjHKEo+wzYFuKE23+F+pqKof5n6otBEEYO8KOEPimA6no G2GoXW/dnx8aZ1loCoeM+nMEcXtdPwj1+EK54H5o8tYCxya+jqKEBKHUFrEaPwiJnGrHVu2p 1igNjtAqoGIf4v27lvCu3e145BgIVvA3X7iIB8fVwnhmdpbvXH0N37n6GgBaikVe2bebvu1b 6Nu6iXVrVsX/eEoJ9ar6NRc9BoSTiRbU0e92yiRNleqFpIcffpif/exnWJZFGIbccccd/Oxn P+M1r3nNMY/iXrZsGe9973tpbm7mscce42tf+xrj4+N8+ctf5hWveAW+7wNQq9Wiw0ieTUkp j3mM+hMdXZ4qVapULyU5y/K2yjrnbBxbsDzvcKDqsyTvKK5zTnOf8yob3d7kRNxn11blZPa5 Q3OiFbdZudjjVcWBdiwRuc4r8orr3NnkNmSfO5sdhmY9OpodHEdErnR7k+JGGxe6Pa+ulwsu g7M+Hc2qfbngMDij29uCclG50J0FVe5pdRma9VnRpObfVXQYmFGuuGsLultc+qc9ykWHZlFH HhxhasZjWamZxcunueSvzqFeFwzLTj76Hxfzi8HJ6AeL6ZkZLrvqu1x21XcBKLW28nKdoe7b upF1q1cd5dpIvw5+HZiJX9QbFkW6YTFVqheELr74YkZGRjj99NN58MEHGRwc5KabbmLXrl1k s9ljurVLly6lr6+PbDbLzMwMX/ziF5mYmGBgYCBaQBv391epUqnw05/+lOuvv56RkRFyuRxd XV28853vpKurCyEE99xzDzfccAOPPPII09PTlMtlfv/3f5/Vq1c/pUxzrVbj2muv5Yc//CGH Dx+Ojuw+99xzn9RGyFSpUqV6IcqBODschIrjjBDYgKfLQihHOUTzotFcZ4PL0PxoL5RkdAja MhxnG0LNk/alJKMtaUe3t/WORMcCP1DHd4N2sAN1XaIcZC9Q/UvTPlRrTYkaxwvA1eatbQn8 QGIbrrRp7yi+tZq/mqeUKnvth+p1BFiWcszN+HlZxx8ZoehA/7xgQ/c0F/7lOdTnBIfcIn// n9fzs0cO4gWxazM5NcVlV36Xy67UC+pSiVf1nUPf9q30bdvE2lW9x/4aNAygNo+szSdeFAiz kE7SQNINi6lSPac6fPgw1157LbZts337doIgYO/evdx444387u/+LqVS6Zg8Z8uyKBQKtLa2 snjxYkAROObn55+U41yr1Xj3u9/N5ZdfzuzsLK7rEgQBYRgyOTnJRz/6UW699Vbe/va3c/jw YZqbm6lUKoRhyFVXXcU3vvEN1q9f/6QWvZVKhbe85S3ceOONeJ5HLpdjfn6e73//+6xfv57V q1enp/ulSpXqRS1HoE8frAYszzsgYEnW5kAtYEVOcaGX5WzGNLcZYHneZnzeZ3mTg43KPo9X FSdaoE4rHK/5tOcUx3mFdqVN+/Ymh5F5L+JCtzc5jMz5lAvquNhOfTphV0FxpTuanCj7LIFO XS4XVPtywWF4VnGjIXaxu4rqSPBy0WFgxqOnJc5SD876dBUVUcRkobvN9aLD8IxHuUURPsot LoMzHj2tGSSSrrxk+LEhulvHCW2HUmER//2+HdTrFhPucj7x1av54X3DVOqN/whOTk7y7e9c ybe/cyUAi9raeEXfOezZvpW+rRs55fEW1ABIpImAJGU7Kk+dSSysnfTUrVSpni3dcsst3HXX XaxatYpTTjmFYrHI3r172bdvH7fddhtr1qyhUCgcs60Qgttvv51rrlExsOXLlz8pJF0QBLzn Pe/h61//Os3NzezYsYNXvvKVSCnZt28fzc3NPProo/i+z6mnnsrOnTsplUqMjo7yjW98g717 93LeeefxkY98hCVLlhz3Pd9zzz3cfPPNFAoFXv/617NmzRomJycZGxvj0UcfpaOjg2KxmOak U6VK9aJV5EAn/z8XgSw0kUNIgaUrSJngO+vKiWizOuhEqoIhaAQLuM8Nv4u4oUwUF6qBL212 sBtCiLkgQehsdoPkgvtL0DvMQS3JcUKpfh2LJLJw/o70yU+Nc2R4mHJrnlLhAP/+vu1UZ2Em 085nLvwe1939GJPz9aPu6cjEBN++/Aq+ffkVACxetIhX7dnN7u1b2LN1Eyev7DnGk1igwIdg Fllt3LAoMjmkk0Vk9e/phsVUqU64giDg/PPPx/M8TjnlFLq6uti2bRuXXHIJ+/fv57rrruN1 r3sdTU1NDTGJSqXCFVdcwZVXXsktt9zC0NAQpVKJvr4+Wlpajtu9HRoa4tZbbwVg48aNvOMd 72DFihWRAzw7O0upVOKUU07htNNO47777mPx4sW0tbVxzz338MMf/pBHHnmEoaEhWltbj/u+ q9Uqc3Nz2LZNe3s7fX19dHZ2Uq1W8TxPHUiVLp5TpUr1Ipajjs0WLM2q7POynINlaRe56rMs a2NbghWauLE0r7LMy3X2eYXOPrdrAseKvINtKVd5tOKx3GSjtctsuM6dTS6j86rsCCg3O6qs Oc+dzQ5Dc8q1diyVdR6e81R7W5WH5lR9x1Iu9NCcT2dBte8qKte4s6jK3UWVfe4oqPlF2Wdd 7m5xGZjx6GpR/feUXAanPTqLbnR9cNpX/dmC7laXgSmPcovuv8VlYKpKpzxEfv4wBcsmDAf4 9Ls28Q9zW5h3F/PF7/yIK259kPGpyjHfjMNHjvDNSy/nm5deDsCSxYt51Z7d7Nmxld1bNrKm t/v43lUpkbUK1CrIxIZFnMyCbHW6YTFVqqcjs3mwra2N008/nXw+z6pVq9i+fTv79+/n7rvv 5t5772Xp0qUNmwlHRka45JJLACgUCpxxxhm89rWv5bTTTqO3t/e44xTDw8M89NBDAGzdupWu ri62bNkSLYalVBuxbdumWq2SzWa5+eabGRsbY3JyElA/BMzOzj6pzYErV65k5cqVPProo3zl K19heHiY9773vWzatAnLsnDd9OTWVKlSvbilVk+atGFc5gaf0vCeUdln4zDb2ioOARtzimGy mXGJ41ME5YJ+0VzohgG1DW0lXeJEe6EnY1mx052cZ2RjmzEa2sdc62iq2rVe+Fo0V9NeNDr1 0b0e9W+OAl1bYUh9+gj5R2dosm1aMy383bnr+Otzz6Rql/jy927h0pv38tiB6YUdRDp0+DAX XXIZF11yGQDLli7llXvOoW/bFl6+7UxWdZcft+0xpTcsykpyw6KFyOSRTgaRzUeL7JRZnSrV r9all17K4OAgpVKJb33rW1x99dVks1lmZ9U3QgMDA/zkJz85CkPX2dnJtm3bWLp0Ke3t7Sxf vpzOzk5OPvlkenp6jntT3+TkJEEQ0NTURGtrK11dXcd0sPv7+/nABz7AD37wA6SULF++nOlp za6X8klTPsrlMv/xH//B+9//fh566CEuuOACvve97/HGN76RL3zhC+kCOlWqVC96OQerivMc SMnSnCJytOdtAikjV7m9yUFKaG9q5D635x1Gqz6dTYrj3K6zzp1NmuPc5GoOtOJMl5tj7nMY SpVd1tlnL4SOZpcRnW32Q+gqOAzN+nRr7nNXs8vgvMpC+4bjrLnPQUjkWncVXIJQ0l2Muc8+ UrnSsx7dLYoD3V106J/26S1pTnSrInD0tCqutHGZe0pqvO4W5Vr3tLoEgaSn5LJ/0qO3TV8v Zeif8ukpqefX3erSP+XRU7KwalPkR+/lwKRHecVS/vKNa/izN51JNXDZV2nizz75Re4bOvyE b9aBgwe58OJLufDiSwGFwnp13zmRQ/2kF9QAYYiszgFzyNkJ/aIAN9PoVKcbFlOlatDExARX X301Qgiy2Szz8/PUajUsy0JKSalUYnJykuuvv563v/3tDRGJXC7Ha17zGtauXUtraystLS2U SiUKhcKTWny2trbiOA61Wo16vU6hUDjKvZ6cnOQNb3gDe/fu5eSTT442Nn7961/n0KFDT+ne hRD09fVx4YUXcuGFF3LNNddw33338Y1vfIN169ZFiL5UqVKlerHKiTjNVkylABXr8HS42bjL ydMAbcBHO8yAaym6hWWpBrZQ1IukkxyEsbFpqBomBp2xBWEoEZbQXGjFZTbury1U/0L3ZQki bjQoKocfJLnQiqIhUKcROlJROwz32rEV9cPSrrVrqfs1JylG4+v7cUScixaAZQt8XyrzXOrx gtjhti2LwHCxLYGNiMpOfRr6fwkSJr0mzlh9Ejf8v3dSr7n0V+v8xWe+yR2PjvKrvlE9cOAA F1x8CRdcrL4Kbl+xglf2nUPf9s3s2bqJ3nLn8X4OFkidrii9WuPL+oRFaWIgTlYdZZ4q1UtQ P/vZz7jzzjtZtWoV73rXu6LFrMn+3nDDDVx88cU8+uij3HbbbfT29ja0z+fzrF27llKphG3b WJb1pHPDHR0drF69mgceeIDvfe97vPOd72yIYoRhyMjICAcPHqS1tZV3vOMdrFu3jpNPPpnL L1dRsaeSVQ6CANd12bBhAx/60Id485vfzFvf+lZGRka48cYb+fVf/3VWrVqVkjhSpUr1opUT cZ+zitu8PKcIHMtyNhn7aO7ziiaVVV6Wd3Ct2IVelrNVFjqnXOvlOYeMI+hwVP2I+9yss8x5 xV3u1C70iryD6whF2Jj3o+sN3Gdb0F1wGTDcZ5N9ntVZapONnvHoKMRc54EZj/aI8xxnn11H X5/26Ciq6+UW097FdXQ2etqP+uvRrnK5RXGou9tcBqZ8OooOjm1F/XUWXWzboruUYWCqTmcx g2Nb9LRl6J+o01nK4toWHU6dgXt/QUdLhkK2wLrFZa7+2O8SeC6DXp6//tyX+fF9/Q14vMfT 6NgYX//mxXz9mxcD0NG+glf17aZvx1b6tmykp7P96X1aEicsRskZy1KbFBsOg8nqnzxSpXpx ymwerNfrnHzyyaxevZotW7Y0nNC3fv16br75ZoaHh/mf//kfXv3qVzduWBYC13Wf1oa77u5u Xve61/HAAw9w//3384lPfII//dM/BdTR4sVikW3btpHJZDh48CA33ngjZ555JjfddBP9/f2A Or67Wq0+0TBH6dZbb+W//uu/+KM/+iO6u7up1+u0tbUxMjKClJIDBw7Q09OTLqBTpUr1olVE 4bAt5bDalkBKsFAnCdoCAmR0kp9tCYQFrq7vGAdYnzzo2CqbbAnlyDqao2zrkwEdSzvWtqpv uM+GK20L0cBldvR8HFufJKgtYsdSJyW6Ogud5EpL7UB7un0o4/HMt5uOBV6guM9SJMY33GnN lXYslRF09fi2GV873k7Epbbw9Tykfo6Bnq4Mdf0wxLGs2CEPQhzHjq4H9XnsA48w+OC9dC9t 5aRSB5f8w2/jzcF4WOQj/3Y+1//8Yebr3nG9uSOjY3ztom/xtYu+BUC5s0MtqPVJiV3ty5/2 B0iGIdQryPqCjZEmS53JIszC2k5zkaleHHr44Yf56U9/SrFYZPPmzSxdupTly5c3bBTcunUr 27Zt47LLLuOWW27hwQcfxPPU391jnfKXlMkk/6p6tm3z4Q9/mJtuuom77rqLr371q1xxxRUE QcD09DTvfOc72bx5M2eddRYXXXQRP/jBD7j99tuZn5/n9NNPx3EchoaG+Ou//mtuvPHGJxw3 ufh/7LHHOP/887n44ovp6OhgYmKCiYkJ1qxZw2tf+9onheJLlSpVqhei7N9a1fL3BcfiUC2g xbUQCAquxYGqT2vGQghodiwOVgNaMmr12exYjFd9WlwLhKDgWIzXfFp0/aKr6peyNpYFBcdi rOLTmlVc6ULGZnTepzWr62csRud9SlnVf0tWldtyNpaAgmsxMu9TyqnrxazF6JxPKWshgJaM xfCc6h+hykNzPovyavxixmZ41qctb2Hp+Q3N+rTl1FemrVmLwZm4/5aczdCMx6K8jbCgJWsz NKP6E0LNb2jKp61JzydjMTTj05ZzAEFL1mZwJqAt74DQ5WmfRU0uCItizmFoyqOtydXjOQxO ebRpTnZLzmZoskIbc4jD/TA9glWb5rfOPYc/e/1u/vdvvoHpiSP0HzhC1fOP+82enpnh7nv2 8p1rr+Nz532VL3/7O+x9dD8zcxUWtRRpKR6bVfuUFAZq02JtHuanYWYCZiegNofwagq/J4TK Vaf/0KZ6gWl4eJjx8XFWr17N1q1b2bBhA0uWLMG27WjxaNs269evZ9++fRQKBU455RR6e3vx fZ8lS5awefNmVq1aRS6XO2qxWa/XqdfrLF++nE2bNrFy5crHzUbn83l+7dd+jTAMqdfrNDU1 0d7ezo4dO9ixYweLFi3irW99K4899hi2bbNkyRLOPfdc3vjGN3L48GEcx2HlypWcdNJJdHZ2 UqlUWLp0KRs3bmTlypUUi0Uee+wxFi1aFL22adMmcrlctFly8eLF7Nq1ize+8Y2sWrWK008/ PeVAp0qV6kUtcfkrylICh+vq4BRLKCf2YC2IDj4BOFgNWKEPTgmAQ7WAdn1wigQO1Hx1kIpQ XOWG9gLGKz4dTW50kuF4RW0eNMSLsYpPudnF0lnjsYraDIjuf2ReH5wi1Phj8/HBKRL0QSzq 4JQQyfCcT0+Lbi9geNanq8WJstgjcz7draZ/ycisT1eLG3Gth2fVZkLTfmhG1RcCwlAyPOvT XXJBZ5uHZwO6WzMgVJZ7aDagu5QBlAM+NOPTU8qAZRGEkuFpn+5Fyq0KpWBo2qO7LavbC4Zm 6vSU1PHdAYKhqTo9i3JgOZBfhrXiJKRsYpImPnPB5Vxy012MTiToGk9B3d1dvLpvN33bNtO3 ZSMdK5Y9rf6OR0IIpJOJNipGbnW6YTHV81jmlL/7778f27bZsGHDMTfNhWHI4cOH2bt3L47j sGHDBqrVKg899BC5XI4NGzaQz+ePahcEAaOjo+zbt4+mpiY2bNjQQPE41jgzMzPs37+fAwcO 4Hketm1TKBRYuXIly5YtY3Z2lnvuuYeZmRls245c80ceeYTZ2VkWL17MGWecwezsLPfdd180 biaTYXZ2ll/84hcIITj99NNpbm6mWq3ywAMPcPjwYTzPQwhBsViMxkvjG6lSpXoxS1z2irK0 9aa8A7WAJRkbx1YHoIxXVBba0cd5H6io7LOJbYxXA1bknWhT31hVZZ9N/VGdZbYttVAanfdo b3aj9qPzKsts6QNXRjQX2hwfPjTr0aG50JaAgVmPzoLiMgMMR+1V/0OzMfdZCBiY8SgX1aId CwZn1KLdtB+c8Sm3qPGFBUMzMfdZtVeLdHPc+MBUzIkGVe5scbEt1UDVd7F0B4oTncHW5f6J OuVSRteHgUmPcmtG1Seub9kWQlj0T9Yot2aj9gOTNcqlPJbeOTk4VaervYzbs5bQa2JO5vm3 S6/lohtu5dGxJyZ6HI96u7t55Z5z2LN9C31bNtK+bOnT7vO4ZbtH56rTExZTPY8UhmG0cHyi HLNxhk09KSW+7//KdkEQHFc9I9NvEARR3MKyLBzHwbZtpJTU6/UonmFe9zyPMAyxLItMJoOU 8qj7Mm0BMplM9NqxxnNd97gxfKlSpUr1QpUDiRP9dHbXkCbMNZG4DsrxtYSIKhlOtPlzsr2w 4l3egrhico/ZsU4JjMvqhdD8eSGHOVEnUoIFLcTj/NmK+dQRP5rExPUNH/Vvlkj8LkR8ww3j Jiegyw1gacy94nI6AAAgAElEQVSDiTEfx7qxheUklUNYis09fwj/4Z8ipWDWL/Kht23hw29/ NdUgw82PjvHhz/8X9+wf5alo/8AA533tAs772gUArFrZy6t2n8PubZvZs20Ty5csfkr9HpcC D1nxoJI8YdGKctUNx5enGxZTPQeyLOsJXeFkvWQ2Gjiug1Js2z7uA1WgcVPi410/1nwXvnas eo/32hONlypVqlQvZon/PKtdLs/baiOcEIwZjjNqg97ofEBns0MoJa4QjFVVFMNsuIvqa5Tb qI5amA2CJloRSolrCYbnfbo0F9qxRBTNMBsSh+Z8uotx/4NzHt3muk3MfdYbDQ33OZRqQ1// rEdvUXGpHVvQP+PR2xK3H5jxFRdaXx+YibnPtgUD057iQku1gbB/yqO3lFHzsYUuK260Y1v0 T6tohpqPpbjPbVm9YdGif7JOb1tW92fRP1Wnpy2LHwo1v8k6PW05AimwLVXuXZTTGxJt9k9U 6V2Ux9cbDfsnavQsysfjTVbpWdQUPf/9hyv0LmkmdFvJdZ6EyC7DD7I8MFnhAx//PD97cP+T OnHsibR61Speufts9uzYwlkbN9C+/JmPfBxTbkZFP5LM6vSExVSpUqVKlSrVMyRHpxsQmrNs a1PVQWWFjbdnCYFvjFTtVIeJhVgDpQNN6QjViYGgOM5+GDuxhsoRt9dcZ23M2jqLbQndh1TX 9fAR59nIthZwoIXiPtv6JETDjVbtpaZi6PloWoYfxo6z4T5b2qm29P2Z52Hai6i9um7ccNtK lIXAEeBL7cILgeNYBEEYndhoW+j66gYcAX7iumPFHGmE0P3H7rtjoTnUqmx5U8zvu5PhyRq9 K5awbkkvN/7rBwkqFvvmBH/+qS/ww3sexvOf3AlkST2ybx+P7NvHf3zlawCsW7uW3bt20Lft TM7edBornq3Ih1dHevXG1yw7dqqTC+tUqVKlSpUqVaqnKXHFK8vyYC1gqeY4g9rgtzzvRKes HKz6LM07uDprPFb1WZq1o6zyWNVneVZxkgUwWjHcZ0BvCFyRyDaPzKmss1lsR9lnWy0wh+Y8 OjTXGVDlZhdHAxuG5mLuM+isdEHPV2efOzXXGZRr3dms5iNQrrPhPiNU9rmj6OLo1fHAtMo2 u7ZAIhmcVllox4mzzx0tLo7JLs/4cRZaX+9sVdxnKWFgyqezlNEIO8HAZJ2OlgyOE2efO1tV NloI5UKr9urr24HJGh2lXKJ9lc7WPI5jIREMTNToLOX08xD0H67QuSinnoeE/iNVOktZlU13 8tRyK2jtPYWg4jBYtfjQP3+J7915H/O1BYvQp6l1p65lz66d7Nm+hV0bN7B86TMY+TgOCSHU ITDJBXV6wmKqVKlSpUqV6kkqPolQnzyY0YtOS6Adac1xRnGXM4IojhFhmfVJfn6ivS0gCJTT bOIhXiDJOLo/K+Yug3KsTexDiNjBNdeNQ+3aiqtsHNuI26zHdx2BZRlHXNVDxicPuk7sYCfb 2yLuXwg1XpL7bE4edJzG8RxLIEMZOdC2bSGFwLYsFbvQi3pVP8Sx7YhbHXGkZdzesS3lkFtW FBORQuDokw1tSy3Kbe2AK263jBxoR3OtnSSHW8qYO02Fkf17yczsI7BcOlo6+Mbf/DaEecb9 DB/9969y5S2/YGJ2/ml/uO67/wHuu/8B/u28LwOwYf067VBv5qyNp7FsyaKnPcaTkZQS6lVk vQpzU/EF24kpIGZhnW5YTJUqVapUqVI9jsRVrypLUASOjrwT7WU7VA1Ynnci7NyBik9HU4yp O6AxdtrkVNi6vBNtKByv+HQ2K+yblAlsHXG5Q2PrJApL11VwESgM3WgCaxegiB1dRTW/MFQu d2ezno9QWDmDrQtRrnZX0YmOIE9i7UJU/a6ii7DU+MMzXoypQ2Hvult0WUqNoVPtj8LWScnQ zAJs3azG1gmLIIThaU9h6/RCeXjGp7uksXVSMDRVo7stp6M0MDTt0dOW09dhaKpO9+K86j+E oZka3W1N6n6kYGiySs/iJpBStZ+sKewd6geBoYkqPYsVLisIQlU/ug4jMwG95W7c7rXIWp6J MMsnv/Itvn3T7YwemX5GPnynvexl9O3aTt/2Lew6YwNLF7c9I+M8JekNiw1Hl7uZdMNiqlSp UqVKlQpHIAiQEc/ZQi04pWykbwiRoGkkcsVCxFlow55YuEdNmuCzrmD6Nfi7UL8u0RlemehD LOivgbAhogV78nfVPm4U/THRFmIQRvJeidrT0H4hjCOqK1CgaIP4sPQKvBHnEf9u+kpSOdTR jVG+WV0zhA/lcEdvUGKO5hnEeBQZ31BSDc8veTPmDyFh4OFPDxHcO0QQCiqyxKf+6OV86g/f xKzMceN9/Xzon7/Eo2OHjvUknpJ+uXcvv9y7l89/6TwAzjhtA306Q71r02ksLpVO2FhPWrLx hMXoESaZ1Qazl25YTJUqVapUqV5SEle9qiwtvRAd11llW68mD1R8luZtHM1pHquqw1ZMrGK8 5rPCcJ9RrnB7k6M3Iioix4p8zIUemVcudpR91q62o+sPzynOswVgKde4o9mJNjYOmXIi+9xZ iDnNg7MeXUXlWmOpw0s6TPZZCJVtLqr5SKFc584WN0L1Dc54dLW4irMsYHBa929rrvS04USr xfJR3OdpzXGOsswe5VZXc5wtBnS22dYgasWBzurxBANT9Ubu80SdzoUc6NYcdiL7XC5lo/n0 H6lSbstFz6P/cDVxHfoPV1TZVovs/iMLrh+pUC7lIqzhwJF5yi1ZnMIS3M6TEc5iqrKJvQfn eO/ff5q9/SPP3AcTOOP009i9cwd7tm9m18YNLCq1PmPjPS1ZtlpQZ/NIJxPHQFKlSpUqVapU L0o5Bt8m0JusJEghI/qDOeQk6T4rDjRHObWgXxOxSWpc4sjgFTFCOWqf+FZcSokUApFwkRey nKWU0WEiRw1vxpexI53kT1tCXTfREXMvpp9QgpDq/mPnPb43PQv9AGKXOPoV1Yks4oSVn/Sl Gx+KiG6ysQ8RPSwi91hGTnriJpPWvhn+WG9O/MYsuKfEAzQXZAhIwvlD1B46yMCRCt0rVrCp YzV3/Of/wfNs7p+o84H/7/Pc+mD/CcPjmWn9/Be/5Oe/+CWf++KXEMDGjWewZ+cOdm87k11n vIy258uCOgygNo+sqdy4+gJBRJsURbphMVWqVKlSpXpRSZx3drvsbHaiDXHjFXUEt9koOKZd 4hC1MW20qrjPhuNsuM9+KMloznPZcJ5twcicR1fBJZBqo+Bwgtvs2oKhWcV99kNdjuqr8sCs T3dRc6ZtlS3uKrp6w51gYFZxnj3dfnDWo7slwXWe8elpiTnVA7MePS2qf8dWrnFvq4sXqg2G A9O+5kLH3OeeVl3fEhH3OeY6L+A+T3n0tmXwpcCxLfZP1OldlMUPwHEE/RMePYuyBKFQ/U/U 6V2c05xni/2TdXrbcrr9MbjPE9Wo7NiC/Yer9C5p0hsILfYfqWhutNRc6Hl6FzepsoD9R+bp XaTLFoobvTiPH4SKQ32kquery4fnFac6DLEFavxSRr1fuRKypYt81xqCmsujc4IP/uPn+dHe h/GD8Bn94FpCsGnjGezeuZ092zaz84yXUWpteUbHPBESjot0sohsTv2eSTcspkqVKlWqVC80 OSYy62rOsE5HKK5yIi9roagcRoabbGn71tXUC+NWOwLCUGLiIY4guo5Q3GQviLnLri0SHGQ1 vhfKKF5h2kfjawqGMVRdw2U2HGRLUTdEYj6+lJH7bRNzo1X7uL5qH19X4ysOdsx1TnCZUVSM 5PwVFSPU5rrAsUlwm4WuD8JSTreT5FhH7eOyLRSn2zjShhpi+ou41AludENZv19CO9+N3GgZ UUGEkNGJlEEQRua24niHCG1/OwK8+SMMj47Rc+AXCKeJlYt7+e7H34Ukz2DV5f989j+47s77 qNS9p/LZfEKFUnLHXT/njrt+zmf+VS2oN5+5ib6d29m99Ux2nvEyWluKJ3zcpyvpe+B7yKo6 YVG51daCY8u1Y538RiFVqlSpUqVK9byRuOY1XXK8ojnPOkpxsBKwNK85z6js87JczH0erajs s+Esj1V8luZsMgs40IYLPTLv055X3GYhYHjOo6PJjbjPw3MeyxP1h+bVdUfvzRqe0xxpJ84+ q2yzziYny2juc0FzqIHBGV9xohNZ5nJLzJUemPboKLhR/1FW2tSfUtxox2SRp/yYAy0EA9O+ ykbbFkJA/6ThPuustOE+u1ZUNtlmk5XuTHKhJ+t0lLKKAy0lA5OK8xzVn6gq7rNlR1nnzrZc xCRMcp9BZZ87S9mImx2Vk/VbMyoLLSUDExU1P0FU7mjJRJzs/sOqviqrLHVni+JoSykZmbPo 6T4Jp2cd+E2MexYf+bdvcNXPfsHkXOXEf4qPIUsItmw+k76d29mzfTPbT1tPS7HwrIx9wuRk GhbUIpNuWEyVKlWqVKmeD3IiB9YiimWE6JMHQ+VUKi6xPqkwOjlPOZZmEZ2xRdQ+ed3RDqs5 edAc7uFoh9i1tQNuiyg2IVFR0Wh8aTjOEltj54wD7dqxg2tiGxKpHOho/vHJgYaTbAk1vmPH /Rvus+nfxERUe0vFNljAkbY1B1o/H0dYirsskuMLHNeOOc1Y2uHV7WWo56fmESKjkwgVF1rF Q1RMRCCl0JzoEMeyVHtLRMePR2Ud25CofvwgjBa5DRxrGc/f1jl4W+jnIczzEfi+bi8kjiX1 +4vmWCuH2xYCrzaPd/BBquMPYDsu0l7Bf/756yB8O0fCPP/43xdxyY/vZGzimcHjgXKob739 Dm69/Q4+9S8q/rJ182Z279xO37Yz2XH6eoqF5mds/BMiv65+MQPo6LrtxHnqZLY6VapUqVKl SvWsSVzzmi4JcKAa0N5kR1/5H6zG3OdQSsV5bnKiTYIHqj7teTciNoxrLrPqFcbnA8oFp4ED 3ak5zxLFdS43O1hCnfY3MudTLrjRPryReZV9RqiF/UhFZaeBiPvcXTRl5UobbrNEc5+LLggV PRmeVdlms0dvWNc3/Svuc8zBbuA+h/q64TyD4j63uiAsXfYVFxoIEQxNefQszgEJ7nNbVrWX gqGZOt2lBPd5qk7PIs1ploLh6RrdiwznGYam1XVpONOTtUT94+Q+L87HnOiJqp6P5lxPVuku 5QBJGEqGJit0t6n+Qj9kaErXl1L1P1mlp5QFGRKEqOulDEjdfqpOd8lV/QW6vCiPXezA7V2P sJcwQ5a7R+d5z9/9I/vGDp+Iz/Nxy7FttmzezJ5d2+jbtpntp62j0Pw8X1A/noQAJ6vdarWw Fm5O5ZhSpUqVKlWqVCdcUQZahQdEdHCIkZRxrlfjigHlUBt6RxLqYA5aiTtI/NHwlnW02uSj pSRiMlsCfJloaogT0sxFRKAIk8+VqMxyBMKI2stjji81fiOec5yVVpSLx6FJGGKIyWIbpEjD fJSVH1M1iNjWDRNJPLOGQpIDjf498fwbQNtC/+eJ6BcLgd4ITdcw+WkZjZd8NtH9mhekTDzY MH5fzANI/vnoSahfoUcw1U/9rscYmvJZ1dXDru613Pflv6ESwC/HQ973sc9wb//o49/PCZIf BNxy663ccuutfAK1oN6+dYtyqLduYvvp62luanrG53FCJCV4VfXLvITasBjnqrVjbbvP3TxT pUqVKlWqF4nENa/pkmajXpR91gvbsWrA8pyNHZVVtjniROuyORAlyj4b7rPhNutV98icR0ez G2VpR+aVa22JRPZZX4+4z4W4veE+W3r8wbmY+yxEY/ZZIBiYibnPCMV5LrdoznSibAtT9ikX E9znScWJtjWIemDaV+21sxeXBQiLgSnFgbadJMdZlxGPz33WK/j+ybrmNGtu9ERVcZkT2edy KZ/gNlcpty0oPx73OSrnVMxFSt1/Vj1PnXUut+oykoEjFcqtGf1Dk2TAZKX1Ir5/oqru31yf rFEuuMr4FKj+i25khKr2bqJ9TbeXWIXl2IvX4HachBe6PDAhef/H/4VbH9x/wj/0xyPXcdi+ dQt9O7fTt30z2zacSlM+/5zM5YTKsmK8npuLYyDphsVUqVKlSpXquOUk3WNQC8/Y6JQNGOPY U1VZ46iNOPafG4xUiJjQQLRoNlVkVCfR3hieCxzWJHYZaDhdWehIhi1iZ9w42cnTDa2G9qKh fWSuJuefdGaTk0Agoq/KRWzRH7ND2fByZJ/rh6meT/IpxxM4ymRO1kva7g2SiQewsHls3wtr YXNtsUfuc+PcFx7N2OBci0SdMGFlS7ng+TXOJZwdZ//QIOV9N+E0L2LdipO58dN/hBQ5HpkR fPBTX+SmvY8843g8I8/3+fFPb+HHP72Fj6EW1Du3b1ML6m1nsnXDqeRzuWdlLidUYQi1CtQq jW/Hwlx1Jpcyq1OlSpUqVarHkfjq7g5puM+2JRjTrrDiNgtGKh7lJldvEFQuc7lZcZhdWzCS 5D5bgpF5xXH2Q7VBMMl9dizB8JxPdyHuf2g+5j7blmBorpH7PDjt092qxrMtweCcR08x5jIP znl0FxVn2raVi9zT4hCEauNb/4ziPpsNioMzKvts+h+Y9ugtZaLxB6Y8etvcaMNfA/dZCPqn PXpK2ZjLnCg7lmD/pEfvopzaoOfY9B+p07M4wX2e9OgpZfT4Fvsna4rLLKXiSk/W6FnUpDco WvQfqdKzuEmPpznNhutsCfYfqdK7RHOfxQLusyXYf2guUU5wn/UGwf4jVXoW5fSGQUn/4Yoq ByG2pU4n7GlTXGhHCPZPVOgtZdUGRgH7J1QWOmpvykGIbUP/4Ro9izLRBsT+iTo9JSfRvk5P ydWcaeXC97Q6aoOlBSPVHL1rTsXpOhUpiwxU5virz17M9Xfd/4zg8Y5XGddl5/Zt7N65jT3b NrP1ZaeSy73INvNZts5TJzcsqn0AqVKlSpUq1UtZDqissKFO6LSD4jhrKoMQhsqgWxkqwzG5 zOofV9dSZpc5htsRavNbzElW1AdjTtpCc5RR49uW5iZbcf+hlAjtchqKhDE2bQsCw31GYFsy 4kSr+YvIEBVCzc+XsdMejW/mZ8ecaTiaA21r7rVx1WPOsp6fLfANRzl5P9oVdixLc6mFfh6W 4jonnqeZj5l/kjvt2FbMvdaL+2NyoHVO27GS3GjDnQ4R6shHbCE191lZyYbCEd2/6U/S2F5/ IKL2+vsE2wbfN/3Fz8NY3Y5lNT4fobnT2uq3NeXDr05R77+Tev+dBHaepuJKvvXhc0H8AWOe 5G+/8E2+e9s9TD1LeDyjuufxwx//hB/++Cf8XyCbybBzx3b27NzG7q1nsvVlp5LNvsAPSAkD qM4hq3OJF0UDs1q6WbXATt3qVKlSpUr1EpK47te65IFKwNJczH0e1dlmg6Qbr/osz6myJRT3 eVnO0Rxn5UovzylusoVyndub1XWkIm60N8Wc5+F5nw7NhYbG7DOo7HN7c8xxHk5kqVXWWXGf XUctt4YWcJ8HZkxZZ6VnPJVt1j8dDM14tBddMrYigBwr+9zRYtqr7HNHi4tjLeA+m2zzlKe4 yHaC49ya1VxndBY6G2epNQfa1O+frCuusxkvwX1W5Sqdpbx+PkJznnO6veY4t2XVjlCg//A8 nW15jQyU9B+paG40cX09X5WFnqezRWenZRhnnS0gVFnpjtYMjj4fvX+iqrjVJks9WVNZcZ1t HpioxtnxMGRgoqafHzr7XKezxYkQhQNTdTqLdtx+sk5n0YnHNxxu/cPCwJRHZ6mZ7JKVuKtf hrCXciSUfPy8K7nsJ3cxPjlzQv+SPBXlsll27djO7h3b2LPtTLa8bC2ZzAt8Qf1EctxErlov sJ10w2KqVKlSpXpxKjqVwZw8mLFEwrFVJwkaLrAfSjK25h1rR9U2nGZLEGousrBiBzrJhfYC ScYxXGjlaNqaE20J8HT/oBzTUL9uKBuG+2yOCfcSHGPLAs9Xx3Gr9gnOsVDtAxn361ro9pou YrjWjqqv2qvfJcoxNjEKM/8gMf+I2+zYmhONjjFYCa60Os5bYrjSQnOaZXQyoOMk65v+45MH HVvdr2qvYhtS/x7dL8YRD+PrFkdxn/1AHc8tw9gBtnV7Wwgd2zBcal22k/2F2IAMQ2xkFLuQ qLhKxI0mdqwVdzuejxo/xBZ2FBtR89PPQ7//anwVqwkl2LJOdewBvPEHGZiRrOo9iX/6vc18 9j1vYias8/NRi/f83ad4bPzZxeMZVWs1bvjhj7jhhz8CIJ/LcdbOHezeuY2+LZvYvP6UF9eC 2pywWJmNX7MshJtDuhlEJq9+d3PphsVUqVKlSvWCl7ju1xQH+lA1oD3vRHvODtQCOvIxx/lA zaezKeY4j1UUJ9oscMd1Ntq0H5tPcJ2lqt9VcNQmRSkZrfh0Nscc5xGdZTb76kbmfc2RVgv5 kTk/4jwH2tUuF+P5Ds2q7DNornOifggMz3j0lNT8A2Bk1qerRfUvkZrj7Or2mjPdmgEd/Ria Cehu0xzoULnk3a1ZPR/NfV6UAx11GZ72FDdZCMJQc5/b8tH8hqY9etrUYiLmPudV/1Jxn7tL OYReeA9NqWw0aM7zVD3mPkvJ0JEE99lwoM18As1tXpQHVNRiaKoecZ3DUHGiu9tyjeVSVteX anzDgQ5ChqZrmnttuM+JchDq+bsgIQhDhifrdLdprnYQMjTl0d2q368wZGjaUxxuw5GeMWV1 P8M6C58sd5n3K9TvX9EFLKxSJ5mOU7GX91JB8MvRkPd97LPcN/DM4/GOV/lcjrN37aRv5zb2 bD2TTetOxnVfAo6tEOqERTcbR0HcbHrCYqpUqVKlekHJsfQCNYnYaGABN/4xpmVgSBZqhWyy tUJEmOFEGxk1lkKNFeGJoz8n2h8LKGH6koa0Eedzk6jjiG1MApShs8QRRxlD6FCRjuR8VXM9 MdNBAiZxNNlCRC8RgaJl3D5Jylio6KX4+UQ/oeibkjFpu3GSSRZ0SDwnHYM49rsmFdFEQETa SCJWpGys3jCAIWkk/mwqH+v9OvbwCRpH4sUwUVksaCMWtF/4R7nglwjxDw+wf/8+uosudms7 Z3adwp1f+FM8O8N9RyQf+Pjnue2h/mNM+tlTpVrl+zf8gO/f8AMAmvJ5zjlrF7t3bKVv6ybO XHcKjvMiXFRKCV4NvBpyPvG6ZSMyOZWpTjcspkqVKlWq57nEdb/WJU12djzBeRZCcZ+T2eco 62zF2ef2JlXfEso17mh29MZBReToaHJxhNoMODynXGvDKR7W1y1LLcaH5lR2WUWNBUM662zp 8QdnPToLLrbOVifrW0Jln8vFeP4DOvtsWQLLgsFpzXXWWWCTfbZMNnrKo7PFZKUTWWc7zj6X iy5WIvtcbs1E9zMw6dEZcZwVB7rcmlHcaEtzn1uycbZ5qk5na05zmoXiJrflVH2hss/l1rw+ JEZozrPJRj8O97ktlyjPN14/UlXz1cefD0xUKLdkNPdZZZ8VB1otT6Mss/6hpF9znSOO9GRN c57VonjAcKGP4j6r9gMTdTpb7Oh48IGpOuWirch/UmWdywU7wZVW3O/o+U7FZamz0OWig0V8 fWG5o+BgtrcdEG10n3IqTtcphCLHw1OzfPBTF3DT3kcIwmcHj3e8am5q4uxdO9mzczt92zax ce2aF+eC+gklILMgV+1m0g2LqVKlSpXqOZdjXNmkmytFbEgu9H8M5ticHKgKiQqJ9gtdROX6 6pcSbS1j+BKbkzL2raMxG04yTLCfozk1TkM7zvEJe0nXciH7OTaLRTw5SYOJHD2Q5PjRTSXa RR0n+kuawlJNWsaTTDyUBb8ECGHFjcUxbjaphbzlqLKMbig2j2XCNE++6bLRLRZJ9zk5jQVv sFj4DiT+LCVShiBtfUXPZ4G5fpSSjnQST32s2zOfMyERMnGf+vXK5AFm75tA3PdT7KZWlrSd xNUf+12wCgxU4C8/8xWu//kDVJ9DPJ7R3Pw837v+f/je9f8DQKG5md1n7Yoy1BtPXYNtv9gX khLqVWS9CkkQiO0isjmkk4iBpBsWU6VKlSrVsyjx9b4O2dns4EvICMFo1aezSXGdbUtljTub FUfZtYTOLjtqg6Cd4D4HagPg8Hwj93loNuY0u5ZgaM6Lrie5zr5UXOahWZ+uohNtFBzQHGc/ VBvIBmZV/VAq7vPAjEdvq4sfaK7zjE9Pqx5ft+9u0RxrG/qnVBZa3Z/iOveWXIJA4jhCX9fc Z9tS3OY2zX22LXW9NcFxnqjTu1hzn22L/gmPnkVZveGvsX3EfW7Lq/4toTnQ+bj+RJL7bGnu s6lvxRxn+Tjc58Pzqj9pONDzj8N9VhsIG7nPIuY+h1Jzmiv0ljLRhj7Ffc7E3OcjVXoWZQl8 zX0+UqfHcLQt6J+o0VNy1QZCS3Gfe3XZFvp6m0vgq42DUX3Nte6f0u9/ICPOdk+rqzcsaq62 KSfrm+cxVVefr1D9oDU47dHV4hIE6lC+/imP3qUl3GWryJ38MoRTYtSDv/nCRVx92z1Mz1d/ 9d+i50DFQoHdZ+9SlI+tmzj9lNUvgQX1E0hYilmdzFW7mcaftFOlSpUqVaoTJAXJkOAK8PTJ g5KYW2ziEZbhEKOMRkNJMEakq7nQxiE2XGUrwUk2ueWIa9zAGQY/iE1MW1MxRGKigWlvgY2Z n6rh2MTjJ9obY9RQLISOl9hCbb4zJxI6jh5PxOOpsnohyUUWlsCBmLOMUFSMoJEjrTjO6qHZ SU6zUPQNX6LjE0LVl+hTDUU8nulPLOBMcwzuc8RhJqJmNMxfLuBKh2HkJBsqh9AutCMUh1lo h9xQN6L2hrutd5Hatog50oay4Ye6vWycv35/giBMtFebHU3ZUDcaudOJz48tdP0Fnxehvr2w LfAC5USD+gwHYeyLW+bzK0BW56gP3MPcY79k3LPp7T2Z8977Cqw/fzuHwxof+69rufwnP+fA 1HOPx77ivbMAACAASURBVDOamZ3lu9dex3evvQ6AlmKRvrPPom/HNvq2buS0U1ZHR86/JCRD qM0ja4lgtRBgu9EhMFG2Ot2wmCpVqlQvOtXrdarVKi0tLQ2vSyk5cuQIixcvPqHjiR+8vluO VXyW5pyIAx1ln20QCMarPsuytuI4CxiZU9lnx9bZ5zmf5XmHjK2zz3MeK5oSXOh5n/Z8zIEe nPPoaFIcZ4RynVc0ORGCbjjRPzRyn022ubPgqvkJ5Tp3NKv+EYr73FnU7aUqdxRdxaUW6Cyz vi5g0HCGDafZcJ+jrLLOTpts85SnOMiJrHNHawZHg6jV9WyUVVZZ56z6aUUI+idqMcdZxFzo qP/JKp2t+UbOc1Qf+g9X6Sxlo+fTf6iiy4rJF3Gfddg45j7r7PCRecWZ1qvZgSOGAw2G46y4 zYn2LU7005YqZ6Is+cBETXGbbdO+RkdRvT9x2Yk51Ka+BY1ZZ11/qk5HQY8nNZc7wfXuT2aj pTpNsqMpfr8HptXnxbEEMpQMTCuuuJlvv8lS6x8uBqY99Xkz5Rlddl3cJT3ke9dhL+lkBrhr JOA9f/dJ9h84csL+Ej4TKrW2qsjHjq3s2bqJDSef9NJaUD+RbKdxQZ3JqYV2itdLlSpVqhek /viP/5iBgQEcx8GyLC699FIAvvKVr/DVr36Vrq4uBgYGuOiii+js7DwhYzomhupaIuL9gnIY wyTnWTvMbsLxCwKJZStusGsrvJyj1lzq5EDtYBuH2nCNTXsviLnOrq3H04u8Bg6yANcRUYzD zM8PFPdZ6niILyWuiDnGxkE38/P1/CDmUBuusGOL6LqkkTssUfGNIJqfiE4CNNeNA+04FjKU 2sEPsS1Lc7IT3GZh2msudHS/yomVoTnZMcQWVsx9jjjPMnJko3LyunGAA3U8dtS+gfNMzG1O zld/UxD1L2Tcv+FGIxL1heI424n+ovGl/uaBBe3N/RoOdeP4MuFAO8I8X1WOONz682dbAhnG jr8tNI9cKAdancUicW3wgjgvb1tx/4ZXbmIjof4Gxa97hKOP8NBDD9BTzGAv7uKsNady/39+ iIot+MVIwPs+/s/cPzh2Qv4ynkhNTk1xxdXXcMXV1wDQViqx++xd7Nmxjb6tm3jZmlXRtxMv OQU+BH7jCYvCUpEPV0VAREYvrNMISKpUqVI97/XpT3+apiaF+t25cye33HILO3bs4G1vext/ 8Ad/AMCHP/xhzj//fD70oQ+dkDHFDa/rlqC4z4YDDXCg6itChl4AHaiq7LPZrzVe8elodnU0 AMY1t1n1CmPzgeI+6wXRqM5GS319ZF4TNPSCanhOcaIjDvScT1fRcJ8lI/M+PS1x++FZTdAQ hvMcc5wlhuMcc6NHZlV22WxOHJ716TKcaClV+5LmPIPiCpuyhKHZoLE87dPTpjjRiuN8DO5z SXGYw1CdftjTlgMEATA8Zepbur8a3W1NRNxpw30WhuNciznPkpjzjOE+V2LOc4jmPuvrQaj7 yyMNZ3myEnGeVVlzn6UkCEM1XpvmQPuK+9xTyiCl5i5P1+huMRxmzZUuubq9ZNiUo/Yqex6N b7jPLCib9tPx+xkEulxy4/Ej7rN6/4amVVlKdbz74LQfcaT9UHHAu1pUe6m/legqKK60er89 ugsqGy+l6r+rGHOnh+Z8uguOGl/CZH4ZK9etxymvxrcd7js0xfs/8TVuf47xeMerRW1t9J19 VuRQr1+98qW7oH4iOW4Cq6dpIHa6YTFVqlSpnq967Wtfy5/8yZ/whje8oeH1T37ykxw6dIh/ +qd/OiHjmG/JEYIoD5ykHIQJuEKStwyxm2cJQ+WIiRcmq5rsy4xjsL9JbycGWSjHNHoNNGs6 Hj808Ijkv/ci7mchpSGev8rYmkVWRN9IkiCEgU2YCdFwUSQHaEB0LFDUp0jUMw9YVxALbuCo rqSmYyy4cExQduIGCBNV43GklAikusEk8znZ38I5JJ5NI71DxtSOJHfaPFD5K9ojFd0jTLY/ xn0lPz/Hum3Z+EugsvJGoZkm8ZTDxFQlygFP3n6YmLskzqGbz68MYfbgMJN3HkDecSN2y1K6 O1bzo0+9m9DN8si05M/+8Uv8+N5Hn3d4PKMjExNcduVVXHblVQAsXrSIPeecze7tW+jbuol1 J/WmC2pQpyv6HhDn34VlI92MdqrTDYupUqVK9XzR3XffTX9/P7t37254fWZmhgsuuIDzzz// hI0lbnhdtzSbBGPus1q0jjeUlYvc3uTojW/qtMF2zX229PUVTTE3enhOuda2zlYPzXl0FNxo 4Ts85ytOr16Am+yzrbnNAybLbKmF+eCMT2fRiTjDQ7O+zrKq+Zrss62z2ob7bO5nYNqj3OJE Gw+HphPcZ4i5z47JOvuKa5zIPpdbMnG22XCfDTd6sq44yvonioHJGmXDedbZZ8VpNu3rlEsJ 7vPUcXCf27JRdjfiPuvn2X+kkuA+iwVl6D8yT7k1pzjPUmoOdDbmLi/kPhtutM4q9x+pam60 bj9ZV88zal+Ln6eU9B+pUW5V7090//pbA5N1VtxmtWIdmKo3Zpsn9ftp5j+pOc8izjqXCwnu s84+R9nuKfX5sqKyR1l/qxFlpQsOtv7aY2BGc8d1f4MzXnTaJkD/tKdO11TT15xyF/14GJz1 6Fq2hJaek8muORWcZvqrkr/8zFe5/ucPUPP8p/jX9NnXksWL2XNOvCnx1FW9z/WUnt8SApxM Y67ayaQbFlOlSpXqWdLw8DBvetObOP/881m3bl30uud5/OZv/iZve9vb+J3f+Z0TNp4DimQh F7hyyolLuG8LTEq95sMyf9Yc4aRplTQMI39Rd27cbiH0+Lq2WRzLhKNoyjLRY9J9jpjOIqZy xO616U82zGeh+WsmLwyUmqM6SNyMjCeKTDhPSaeZ+AYj1znxUIQ4xiQ5WsfjAh7lipvOpJ6u cZslEcs52a+xVaN7SEpq91/3l3SbzTBJTDViwX2o1aoMw3hOEiK8hpTqzUx+63AsI3rhh2nB +FJ/LZH8XMgFn9+kC93QXsRGeHJ8c8Bjckjzd6PhMYu4f392kol7b4N7b2MszLFqzcl86y/e jJVvY9Sb58Ofv5xrbr/3eYvHMzp0+DDfvvwKvn35FQAsW7qUPeecxe7tW+nbupG1K3ue4xk+ zySlOl3RqzW+rjcsRrlqN6sW1qm7nypVqlQnTHNzc7zlLW/h85//fMPiGeB973sffX19J3Tx DCAufEWH7My7hKgNWGOVBPfZFozOq9MDpe2SLbYyMDpGOXF9eN6nq9lBFNoQc5MMz2nuc6g2 Dg5VJD1LWvDnprGFYHDecKDBcW2Gpmt0tTgRl3lw1qN3xVK82QlcW7Bfc54NlzriOocJ7nOL SyAl+ZWnM3RkkhXzA3p82K85z6b/AZ3FDQKJbetyqxtzn6dUtllt6NMc50VZAr1Rbf+kR29b TtcX9E/U6VmU0xxnU86rDW22Rb/hPEuhOcZ1ehflYs7zRFXVT5R725cQWBns2pTiOC9pjrnP RyqaG23KMee5kQsdai50RXGqA8OBrtDTluBAN3CfJfuPVOldlMMPgni8tqze0Bhzms2Gwf4j tUbuc7Jsw/7DNXrb3JhDPVnT3Gbd32RdPf8wVNxnzXVOcp8VNzrBfW5xow2DSe6zjXKJFTda fV5ibrT6mWdgWn0+fcONno4505b+lqK76KoNrpZg/3TMkbaF+vx1FXR/utxdcDVyUH1+y80O nqk/61FudpFOlubyKkpr1mO3LeewDPi/X7qC7/z0bg5OzZ7Qv9TPhpYvW0bf2WexR2eo1/R2 PddTeuFIWAg3C5msOgwmq13rNAKSKlWqVE9JH/zgB2lububjH/94w+tXXHEFn/70p/nJT35y wsd0jLVmCxFxgiGmIGRa2uh+x58RVuepTRxi/Ype7P33MHnTZQQSij1rOemD/4/a8D6cFT1U L/wcPPxTHAtyG1/OmW94N0yOE85OMv7lv0UA2fIaFv+vv8JeWmbgT18JqMVIfsdvcNrO38Ce GsNa1MH4f/4p1syIcryF4viu/fPzaG5twyoswmouURh5lKwtmPr23+Oc9moYGKB6935yjoUX Nua0g0TWNeI+AwjBoj+7grA6i/z0b6nnYQmyfe9hw87fY+ITZ+E0l2j98+/hfuLXKbxLBdCt tjKn1qpY84dBhhz58rs55S++pXB92QLeyANwwd8CUHzVB3BW72L15AGyjkXt7quo3nu9dkOF irksP4U1v/UnONVJwjDEWb6G4hWfRR76uXo/wgVcZMNVlvr9Cg33WcbXtTtqqBfG94o4zOZ5 iCTXWyb6UwPYmTyB5yGogZNl0Qcu49BnXqu4z2hKhh8kONrEXGkMRzuM5h9xnHWFmLvdeH9m SWELXb9h/glOuFBUF/ONhbWAK25Zifdfqv49M16ybPozHGndgeGIGxfbcND148JK9ieINtdG PqNfY2rffdy/95d0teRpau/ln9+ylc+/+81MW5K7hgPe89FP0f88x+MZjR84wLcuvYxvXXoZ ACuWL+fl55zN7h1b6NuyiTU95ed4hs9jyRBZr0C9oormdceNNiqKdMNiqlSpUh23LrzwQjKZ DJdccgkAn/jEJ/iN3/gNLrzwQu6//37Wrl0LwLnnnssnP/nJEzKm+NEbeuRC7vNIxWNFTnGV V/3Jp7n1y5/m8OFD9O54FdXhfWQ3nIUz+jCFh3+C7WS4bWyGeS9kzfY9rP9f7+auj/4ea1oz rPzYpXz/Q7/H/UPj/Pa/fIv95/0d7ZURhud83KVdnPqh/+b6972c9oJDZ7OLnc2x79AMtx+o 8Po//luq83Pkf3Qek/WActFVaD0klz88y4ZXvpmes97AVR/939TDkGVNDq9//0d5dP8Aszd9 nXVL/v/2zjw6rqvO85+31qIqVWm11pK8L3EWx9nI5hhISFgOSRqYgXRzYNIMDEsgPTDQdBgI DYEGTg9McoCGhJB9oQmBLJDAhJDVhNhJbOw4tmNZUpV2S6Xal/fenT/ufVUlO3/0OXBwO9T3 HB3p6q7v1avS1e/+fp9fQHKmqftOS19l5RsdMTHNuu/zCV94CBHr4+dXbWFFIE8ibhP/yO3Q uYKvXbqO/37+Sro+8yvuu/JkeqIWowsVzvzQV5ka2cuT993MYNzG0nUu/9aD3PTPnyK8cJBL rr2b6SfuwHnlt6x99/9iz4FRdj98M+miQ2eLzdkr24iHLcYXK/S3txC/8hamH/0+d99zr+Q0 6zo5R6O7xeCM5TEs5TYyeriB84yQ5bagQhAqTnM8UEPajS0U6Y8FMVSK7rGF1+A+xwKYqn50 vii50ap+dKHE+o/+kIVHv4M9+wqj8yV0ITiULnHOUITkYoW+1nr7sYUyfT43WniMpivy/vu+ 0ukq/RFjKfc5qjjMyve5L+pzp4/gPqM42y1HcKB932ehOM9R6fvuqfr+FquGVBzLViWXXLku jfm+zmq8UVW2/PunOOM+Ym88V6U3WJ9/PFetxQYIIRjL+bECylc6L+fT1XjjeYdlQUMhGnWK 8T7WnXgiZu9yiga8NDXPR798Ey+PT/9Z3uTHQn29vTWXj61nbGLl4J+Hu/nXJj9gUbNDte9Y kgbUVFNNNdXUsZPpe7QamuIqG/Kj2dI1wmtOpTw/RapscNnnv8PkI7eTi8cZfeAm3njdbWz/ wuMMRGBZ0GCoK4htlWiJtTORd1i3LIbrVEnNzLG5O4i97xmKgyfCvgnQNPojBpZe9282dA23 XCLRKhNw9BllDre1sz9boTWg1zIjWqbGaT1B1nUF8Wyd7rBBIh5kRdzC1jXsSIxNn7uNWN9y Fu753/DqMxiRdtr+x/Vo4TjFp2/D+/Vd0gKt0m9LuoLG6I7f0n7KhRR33YfVvRxnYQKjYzmu i9ocynvVYhtcsq6NUMymFDJZ2RHkTavjeMoirGtw8bo4ETfDrqJOsCoto56AM4djFKqC4faQ 8rGVnOjA8Gb0UJxHHvoFq7rCnLuqQ7l1aIzMFwhveDOBM68ATaPjuQcwdt+H4wla3/EF4nu2 Ed/yPtL3fpbWrR8mtusp4hdcgbOQovj49xHzr2KGooTe8hmMrhWsWJjCeeQbuOkU9uBJ9J1/ AdFoK265QHX7vaz4m08QjnVRmXiZ0kNfIXbShVh96wm8/UuYrzwKv7yRDVffRvf3rkDXNeKb 3077JR9DoFHecR/eA9/DtGwiV95CadudbNj6MURqJ4t3Xq2SuYg6N1ptMmvcZ8X99i3SS7jP 3muUNU1xs+Xza8rcN+hanfvsu1n74/tp6Ks+Z1pZkH2utIa0yFd9rjXSEu67hXhu3YKuK+yg rizgjfP7mTh9ekfF52J7fuZHgaF7zI2NMHJ4HMeDyLJ+ViXWsv3//gNVy2DPnOATX72e5/eP /eU/Hf4ETUxOcsc9P+GOe34CQH9fH1vPly4fW047hRXNDfV/SMJzoVxElBut1VqNWb0kaFH/ K07l3lRTTTX1F5aua9ATNJksObVMcT0hk8miQ3TlRkZ/9xBnvPVynr/jep598nfk/riNDktQ nksxVnDRNI2hVoupokvPO/6e0V/fQ8zWyfaup5RJ0xUyGIxYHJ6bYfDE0yi6gv6IyUyxftzf HzFJ5qqYhoZtaCQ64wTOfCdTT95PxRUMRCzGsw4q0R+JqMV8ya0dlw/HTFI5B12HNW+5goP3 fI0Hb7iW4mnvJVNxWXnR3zL2zAP89B8uwTntfZR1m9F0pWbhHGi1qbiCsd//ihPOfxtCQGHl m1h88VFAoy1kML7o1Iw+AzGL5GIFtVeiN2qTXKxgqVSKK9edhHvmB7A7+hnd8Th9rTbZssvQ qVvpvuQq1l36ScYXS5jKojzYFiRtdZIb+yPZQpkzhttIpsvYpo5haCzvbMU86/08c8NV3P1P 76PlhDezY97GQEBLO27PRu6/5j388tmd0NJOKb6cX3zpCna98AfyG99FZ4tBYdVF5OeS3PnJ t7Dzdw8xteZy6YJgBoiffBFPP3gXP/s/n+PVsQkO3H4NN3z4Igqx5bzqdRE++DjTB3bywLc+ xU9/8C0ZYBrt4YWJPB4GA2//JPdf+37u/sw7qa6/BDPWw6F0FXPZGmbDy/l/n7uQdKif0cAK hOcxGDUZS1drtIzBVpOxxWotSc5ApF7WNFWfqdYsvoNRVVYWa1nv1P7JGYhaJLMOCp7CYNRi LFutv94Rk/FMVW5+gYGoLBv+/C0mybwcTwP6WyzGc9VaJsOBiEUyW63RaAYiJsl8tWbx7gub pPJOzWLeF5bj+UmI+losUnlHBc82tNegMJNi+rnHeOyHN5B64CesmNrFE1//CLn7v8kLd3yT LSeuqgXKHk9KTUxw+933cuUnP82qc97M0NkX8oHPXsvNP3uYQ6nJY72840wyYJFCBpGeQcyO I1L7YeIAYnYcFmcRhYxs85rsx6aaaqqppv5U1aJW/M3oErqFYZApVWiNhDlcqLAqatMRMugM GuC6hAy9BmUYftdHqeYWeeLuGxmMWui6QcX1CJpa3a/WMJgruXUqBNQYz6C+GSbdH/pXDv3s BnbvfJHhuLUEZOH5GAS/P3UyAgJ2//yH7P3jLvpLo7R29ZLMutgbLsDrXsvZf/tpoqEAi10n UnUb7oJaz9Sup+lYsZGpSojo+nN55bnHUV4fLCVzqJ1Zw68ax1lz3tvpeMO7eO62rxPX8kRs ufNfnB7lle1Ps2f7M4wcLiL8/kIe1TpOlc6IXUuZ7V+h2b+RzMSrJA8dZOugiTe2A3dgc432 /NS938cp5bn4hC4AnnvgNrxyjoGZZ2hbvZnRw0Wia89m+2/uZ0N3kOHZp0mcfB6j8wUEcHjv 73n+mcc5Z3krw6EK7UaFi99yEdGQxTRxEIKwbWCZGhevjdPXagOCfMXFHN5MYWI/yZEDXNBT wTv4LIsDZ+MJgVcp8uD3vkSbVkZPjzGjS6v6kRiM2uPggzpo+L606dG/1+qs55qLs5AEmSNe lvrPWh0eojf+TpE8/GQpS+Z9jf61l6+h3rd4+6zxxvmP4pMfMfzSKQXFwzMkn3+SXXf8gG13 30rHged5+Jr3k7v/W+y551redvoJBKzjE5M2nkxy6113c+Un/ycr3vBGhs+5iA/+45e59Re/ Ymzy+HVdOZYSrgOlPCJzGA5PIKZGEKl9MD2KWJiCXBrKRZnZqammmmqqqT9Juk+36A2aTBUd XBVA1hc2Gduzk4Fz38rME7/g/L//NO6Kk4msPwPTNGgfGGKuWMUTgrbzLqVr3SZu/OLVrIrZ dAUNIhO7oSWG5wl0Dbq7uhl56Q+SvqFDT9jA9eRGQ9e1mlWv7X1fovDK73nhkZ8SC+rEbOkr Ohg1SeYclRZbozNsUHJkXkFD1xiIWmQrHq5TZdOyAMtjkuyRLbtoVojDB3fz8o5tvHTbV1hM HSRkS4KDKyRtwzY0ZrNlyvueYfjiD6Jnp9iZSqNr8rh+sCGLnqFpJOI2uYpXO/5PtAUYW6wg gCdu+Rd23PoVVl56NZsTcSxTJxo0mDh0gPL+Z7FTz7OhJ8LYQkmmOzd0YpU5WldswrADGIbO UEeY0fkSruuhh6K4pTy6rhOwdIKU6OhoZ1cqiwAsXfDmdR1MqPlt0+CC1e3M58poboW5XJVA Syv7U3MMtAUI6VXsQICXJst4LiA83jAUI11y0HvX0vfB6+lsj5PNLFKqyEDAoKmRKbloyPuh axqzeQdhR8nnspzcG2Yu52A7BcKtMWIBA9d16A7prOywidoa2bJHxRHoOiRi0orsuzMkWi3G MlVcocpxi7F0teYm4dd7QpWVVdkT0s1iMGqSzDi4yl2jNp5y4/Dbu57AQCMRUWU13mDEIplz 8JDPayJiMpZ1cFQg6mBEWqE9T266B5VV2nfTGAhbjOfl/IamrNR5v15atVMFB0etT1qdq7X3 R1/YZCIvn29Dg4EWi4mG/rFqlh3PPs3Ou37E3ntuxn7xBe75xGWk//0bvPrTb/Ke804lGgoc y8+SP0lj4+PccsddfODjVzN85gWsOO9irvz8Pzc31H+qhJABi7k0YmEKMTMqN9WTBxFzKURm DlHMglM91ittqqmmmjqupIOPJNZqCSp8S9jcrm3EevpJzcwycuMXcfvWMJ9eJPTG9zH90I8p ux5WWxc9f/d5fvnVT9Ae0FketeQ45QK2ZSNa4mgahE88l9Fdf6AjaOBzkhsNipoG7adfiNm7 ksdu/650/Yia8pjeb+tb/xqti35/358ClV5Rq49b2vUIVms76Z2Pox14gnWBNPGgUbd+N1hE i7t/w+Z3f5x9Tz1E0PJ9ChtNzb7JWOO1rKEg/cdXpJ+jmpmltOm90uqq+BDLYgEG4kG6IoEl hlhnbDvVQoaOky+i6koLkW6H0EIxnNHtRAfXYykfFmvgJCZ3PoWj2ml+hkR1Q0LxTgBahjay uP95dB2K+59leOMZaALMvo3kR16gXC418Ldl/+Cpl7P/kR/z9KM/B89BN0zlwFskFImz5FUT gvKBp2kd3ohtS1qAvXwzEzseo6qsXLqmNdC5VN8Gk+xRJ8ziNX480mOhwWLtNVqtOdra3Ijb lmX/wWh4phqHbjDOCeo+7Y3jLenf0Bak5dpnSvvPqz+n/6iJ17pG9bMrGsY4sl4NUCnkmNv7 Io/e8WNevP3fqD77OD+68kJm7ryO8fu/wf3Xf43O1haOZx0aHeXm2++sbahXbXkrH7rmq9z+ 4KMkp2aP9fKOewmnAsUsLM7BXAox+ap0A5kZg/QM5BelC8hrHgU11VRTTTVlTpUcBlpMHE/Q GzSZKMqyJ6Tv6K4fXce691xF1CvjpGcorXsv7uhOXvrtI5zeHUI7+c1ooQgXX/8QYVMnPzfF 7L/8HUJA/qHvc/oXbyFamKU8P40zM0q6PUA8qEuusg5zyhfa8QRDWy5F71nJRd99nJCpU3rp 1+y69TqG4zaeB0OtZo377AlB0NSYLUoUm+MKWm2dQtWjQ5MbkYChMZ13KW27l743Xs2KL9+N 7jnwzM2UDzxLIm5LrnCbjQA6wgYHn/8t1e6bePKxX3NuIqyO8gWOkEizuYJko7meIBIwyJY9 WXYFiViAasPZv/XkDQz9t5sYP/gkISE49a1X4GbfQottUBl/icFnfsxYuiy5zY5D8aHr2PSO q7AqlxPQHNaFY+y//zvEs/vIPXcf53/qu1iGoJx6mdTBl7n8lB4qjtzxOZ5gqD1IxfVYt+Uy Qp1R4r1reeCbH2ewNUBl54OccMYHMFouJmAb7LjvBk4ZjDJXqNAKuK7LULyFiZeeoO+SjzG4 +Y0wvYdTLv0Q7v2forDzYd764WuY/92PaU8+AUBXxCI5s0DvU3ey+qM3ErNhdt8LTL66m00n dKJrMFtwanvmaEAnOVdlTUcA1/NIxKwl3OdEqyW5zn7Zr1ec71p9a739ocUKwzGbiiMYUL7U iVbJaR6KWRxarCqOs5BWaJ8D7QmGohaHGrjPAxGT0azDUMTE8ajXRyTXfDBiMZ6pMhiVHOxB ZcUejEhOdH/YZDwvuc+OX9/Ahe4LS1///hY5f1+LxXhWZlOsetCvfK/7wyZVVS+zHZq4LvS1 SCt1b9ik6gp6Qibj6RxeZTdTe/+IZVt43QnetOlkxm/9Mhnd45EXp7nm+psYm134S3+2/Fl1 cGSEgyMj3HTr7QCsWrmSLee8oRaU2L+s6xiv8HUgz0WUC1AuNPyyHrCICljUmgGLTTXVVFNo 917YL/pCJpraFB6uuPSFzZpP6UzZoT1gcLBkEIp3MJ0co8XW6QgYDLSYzJRcUvkqUwUXS9PI OC4ntwc5sTOA6wmePOwRbY2SnZ8jEbUIW/I4XgjBgXSVA5kKlwxHMHSNiuvx4EgO15MuAx4Q tnQuWh5GU7SDibzDUEz1X6iwc67M5Wujqr/g3r0Z3r46Qjyo8/JchUOLVd62OkK+KnhpQWNs UfrjrgAACeNJREFULkdPRGd9V4CusMlkwSMRs3EFPLgvy4ZlIRIxm92zZdZ3BZjIujyfyvOu E9s5lK7y/Hie95zSia5rVBzBw68ssqYrxPqeMJ7QODBfZsd4lv+yaRke8OyhDPMFh4vXd/Dw y4dZKDj0xIJomsbaZS2Yps5Qu7y+qit4YTzLnBvC1j0qhQxTi2Uu2dhNe4vFc6OLjM9XaA/r rOwMMdwRZnS+yPbRNO86tRchBMH3fJufffsfaXcOk87lmc6U+K+n9RLU4dDhItuSRToC8p+P k/oipItV5rIVwrbO6s4gycUys3nBdDpHLGQwVzIYbhWc1BPmD1MVXp0pcOGqMOWqyyvTRVZ1 BuiLWmyfKJAtw3SmyFmDYVa024yny2wbL/Duja0IT/Dvf1zk1L4gqzts8ASOJ5jIOiRapfXa cVU5ZiGEpHSkcqrek1SLlGovhMBxYSLnkGiVfsBVFyZzDgNRszZeKueQiMrxHE/I9lGZWMd1 ZXkwasm4LE8wVZD/QPrjTeTlBlkIOf9E3pFlT7Uvyg0vSMrGVMmlPyTx6lVPMKnGE2r8yaJD f9iSWQtd2b8vrNq7gumiS2+4vv6pokToeUJSaKaLcgMthGpfdugJqvaeYKbksixooukGkb5B utZsoGv5Sgqm4KUph49e+232Jl9/LhGrV61k63nnsuXM07jg9FPo7eo81kt6fcsw6wQQn1lt 2sd6VU011VRTfzFpT71zSEwVHboDJraiHkwWHHpCJobiQk8WqnQHDZkswhPMl136wyaWqaNp kMxVWRas958oSCubYWh4QjCiOLwhS7oKJHMOvS2mpBpokMrJTYJlangIxrKqv/IemMjLTb1p yOPwsYzPCW7oH5H4O4FgPOsw2Cq5vwJIZR36Iya6ITcdE1mHgZglXSI0jbGMQ3/UAk3DMHTG MlV6Ixa2qh+ZLzPYFsDQdQQaycUq/TELw9DxPMmVHohJ32VN0zg4XybRHlLINji0UGawLSSP 8jWNsYUSA/EQpqmj6xqj82XFbZZIvZHDJTpaTGxTxzZ0xhdKDLQF0QFXCJILRQbiQSyFTTk4 WyDRJrnQocuu46Zv/BOXDVXRNA1TE6QWS/S32ipgTjByuMBgPIitwMkjhwsMtNpYEszMyHyR noiJresgPEYWygzHbTQEFddjOlOhr9XC0FR2v/kyPVFD+kdrkvM8ELPQEQghSGYk9xmV7XIs XaEvaihuteI+R+rcZ58D3ch57m9R7jwoznNLAyd6UXKYfUqGz3021Os/lpH1Pvd59IjxxjJV esImCgte4z6bKkBxPCc5zrX1KE60j9Qby1Xl+0W5dYz75SO4z6aibiRzVZY11Cfz8v3nrz+Z r9IdrNencg5dwXr9RMGhK2DU5p8oVum0DYn0AyaLst4PaJwsuqwcSjC4YQNtK9ZQ1WF32uMT X/0e2w8cX3i8/6jWrlnNlnPOZutZZ7Dl9FPo6Ww/1kt63UvTdYRpL00GYwXkh0RTTTXV1OtM pn+8bhkajhBY6o+wrkv/Uv+PdsCUbhcRS2Ox4mEaOq4rJGpMaARNDVcF+IH0p/bTZQdMnRZb kwFUAJrk8NY4vqhMdp4aT9PkZlrUqQZWrV72t1R/05D9DZ36/Kqf58mANyHqmQcDpo5u6Fim UUu/LVQgoZ+pTnhgGbqcT5ebdtPQJWfYUNxsQ8f15IYbHFlW6bp1vZ7Zz9TlJtlU4xu6hq7r WKYuA96QmyRT12V6cF2TQWMhlZ5aETn8zHyWLv9JsQwdx/Vq7f37t/iTz5GdGsdaPoC/YZWc ZF2lz5ZrsQ2tlj5b0zR1vR6mBpqAoL9eTV6LYWi4jiBoSQKJZWo4juQjC8BW98v/W2loDZxn Twb6uS6gycBPn/Psbyr96zN1+br7mQfr66+Xa5kDPclVFkJgGdQC/mRgp7TI6qq/pde5z/L5 0Gr310PW+wF7ArluP5Ol8Bq41GrTrWsaVaf+/Jl6w/zI9fqZFIVQ83uN3GjFmVabdFOt3+di G4qL7Y9nGdLCbWhaLZDS51S7Xj2TaK0eNR7y/uSnU+yaTKI/9mtK0U42btzAk1/7CJ5tsy+b 4VNfv5On9ryKtwQ/cvzqlX37eWXffn5w8y0ArFu7hq3nnsOWs07ngtNOobuj7Riv8PUn4XlQ KcmvfEN8imlLC7VvqbaCYByf9JimmmqqKV/aU+8cEgCzJWnl9QOVposO/S1WLRX0dNFhIGLW sHFTqt4APA2mCg6DLZbCiqmj66glraZIq/agOloXSCvaQMRSwViCVN5hKKrKyqo82Fp3JUnl pe8zgNAESf/o32+frZKIWXJ9GiSz0tUD1NF7ziERV2WhyaP9mA1qQ5PMuaoMntBk/7ZAzd85 tVgl0R6U9Z5GMlslEQ8AcgOWzFQZagsCGi4aycUKQ+1BOb4HyUyFRHsYEHK+TJlEWxjU9SXT ZYbaQ3I+IUgulBnqCIJyHUgulBjqCIEQuAKSC0U5vrq+ZLpMok1SGKqOx2SmRKJN1nuuW69X JJFkuqTKMsV2Ml1mKC7xdK7nkVwsk4jbIMBzPbn+uCX7u6Jej1DzVxiKW/VypkoiZtbbZ6vS 1UIIPM8jmam7brieIJWRrhu16/HLQiYeqbUX8vlKZtTzJOQ/TslMlUE1nufBeFb6Si9x3fBd MYR0BRmIWDXc3HjOIRExa4GF41npO+27TqTyVfl8qwC/ZL5ac91wVXlAuWZ4Qj7P/viOBxPK 1cNH7PmnPH7/iXzdVcMTgklV9pF6kwXp6uEJcJGuJj2hev1UUbpy+PNPFR16VX1VCGaLLssa 5p8punQFDcLxdrpWrmFwwwno0SijRZdPf+sWfvPiXipOI+vx9aUN69dxwTlns+Ws09l6+iY6 22LHekl/XdJ1sIINiWACYAYaonSbaqqppv5zy9TQagQBkJ9rjfQCHblBhiMoBCg4QuPn3RE/ N/ZthFj4FIIGcER9rMZ6VbeE+9wAv1hCV2gYowZ58Ns1niDWKAza0vXW5j+CrlFHKTT0U7P5 A/sL8MdotOKJIxbqmxSPIGcsmUOw9HvjWpaMrx3VSNOoJfBYsv6G8RopJuBRg3kfRcmg4ed6 n9rzUpv+iAX7CAohjqgSS4fy+x91nQ3fxdG/9wkVmkqdDQ10jSOWLG+ZVl+KsijXXxY5hn/L NFDUlDpNQ+OI29Iw55L5tXo7odo19vGOWv/S90LtGT7ikv1bUONce0ffMr+zJo6+fYrErtYl 1+GpPvn0PNk/bGPbU0+R6Gije8Vq7r3qMvRoG5Ouy2e/fRe/2r6HXLF85IzHtfa8vJc9L+/l uzf+CA3YsH49F5x3DlvPOp3zN59EZ1v8WC/x9S3Pg3JBBi0qaZqmfKrll2gGLDbVVFP/ifX/ ASef+fjswacRAAAAAElFTkSuQmCC --------------030309090505030906050601-- From mike@mtcc.com Fri Apr 20 07:40:09 2012 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 DE8F021F872E; Fri, 20 Apr 2012 07:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42utq42v3quz; Fri, 20 Apr 2012 07:40:07 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 6F69921F872A; Fri, 20 Apr 2012 07:40:07 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3KEe5JJ011241 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 Apr 2012 07:40:06 -0700 Message-ID: <4F917545.5080103@mtcc.com> Date: Fri, 20 Apr 2012 07:40:05 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Derek Atkins References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1459; t=1334932807; x=1335796807; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20[apps-discuss]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Derek=20Atkins=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=/UA98CGbu4CjErtF1sSrI0tBxipwAJn0E33Vv19YiG4=; b=aVeKBYv12mUHcSA07k7KUi/iou4aATYTWV1hMiUVRChxa8T50izYkYhrss /daDC8jh1h+EqT8PiXvV31fooKxYLKgY+dgmlRy5mKkWpV5Ouy053dCAeTJP 0a75S2SzV05zJ1SznSABYUQwn2o69nghFQfSVJ/S1n7S+bGu3KfL8=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: 'Tim Bray' , oauth@ietf.org, 'Apps Discuss' Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 14:40:09 -0000 On 04/20/2012 07:17 AM, Derek Atkins wrote: > Paul, > > "Paul E. Jones" writes: > >> Tim, >> >> I do not agree that it's harmful. If I removed the WF discussion off the >> table, I'm still having a hard time buying into everything you said in the >> blog post. >> >> I implement various web services, largely for my own use. Usually, I >> implement all of them in XML, JSON, plain text (attribute/value pairs), AND >> JavaScript (for JSONP). For simple services, it's not hard. I do it >> because I sometimes have different wants/desires on the client side. (For >> more complex ones, I use XML.) > As an individual (and not the chair of OAUTH) I believe that the server > should be allowed, no encouraged, to support multiple formats for data > retrieval. I also believe that clients should be allowed to choose only > one. I am fine with JSON being Mandatory to Implement. I am NOT okay > with making it the only one, and I am even less okay with mandating it > is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- you > can convince me either way) XML, and MAY for anything else that people > feel stronly about (although I feel in 2012 XML and JSON are the two > best). I also feel it is okay to say that a client MUST implement one > of JSON or XML, and MAY implement more. > > Why not MUST ASN.1 while you're at it? JSON has won in case you'all haven't noticed it. Mike From melvincarvalho@gmail.com Fri Apr 20 07:44:31 2012 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 1FCBF21F872B; Fri, 20 Apr 2012 07:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTVzThsu0pk8; Fri, 20 Apr 2012 07:44:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC9121F872A; Fri, 20 Apr 2012 07:44:30 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7613430vbb.31 for ; Fri, 20 Apr 2012 07:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2V+R8pNJm2ZGvE8f3fJZJ2gYUWKiOtclUc4urSw3Ja0=; b=gPTWBDlZjBKUisvyglhBKNeADehiSzUA+RIuqkHJw+96V6wYV9lJq5ll18FeMckHb4 YX6Cg+ReSh83uJ9d70yZ6XSZvlfGMhQwp4ZWgvwK3nsc4GNRTN/qunxyyXVT6+lS5Bf2 jkqrI16Jwmro/AlCHuODs3GFxGl3dR9qc7wRyzr5ZpErP3FWFHfQxhtz5C/IvXs98l4W a796zAveRZrmjxH+FbGaZBLRRlbjZQUMk3o6dcs676JjOnf/CUAbow+1VvDe1nuvIIFa G+L9FLqmbE1HUxzKpHDGDe4nimrv2dhagye0dgv3kQ9bZPA1te3y2BqPG/MQLRJcF0Wi DANw== MIME-Version: 1.0 Received: by 10.52.95.147 with SMTP id dk19mr4166162vdb.106.1334933069752; Fri, 20 Apr 2012 07:44:29 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Fri, 20 Apr 2012 07:44:29 -0700 (PDT) In-Reply-To: <4F917545.5080103@mtcc.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <4F917545.5080103@mtcc.com> Date: Fri, 20 Apr 2012 16:44:29 +0200 Message-ID: From: Melvin Carvalho To: Michael Thomas Content-Type: multipart/alternative; boundary=20cf3071d0b66be78804be1d53e8 Cc: Tim Bray , Derek Atkins , oauth@ietf.org, Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 14:44:31 -0000 --20cf3071d0b66be78804be1d53e8 Content-Type: text/plain; charset=ISO-8859-1 On 20 April 2012 16:40, Michael Thomas wrote: > On 04/20/2012 07:17 AM, Derek Atkins wrote: > >> Paul, >> >> "Paul E. Jones" writes: >> >> Tim, >>> >>> I do not agree that it's harmful. If I removed the WF discussion off the >>> table, I'm still having a hard time buying into everything you said in >>> the >>> blog post. >>> >>> I implement various web services, largely for my own use. Usually, I >>> implement all of them in XML, JSON, plain text (attribute/value pairs), >>> AND >>> JavaScript (for JSONP). For simple services, it's not hard. I do it >>> because I sometimes have different wants/desires on the client side. >>> (For >>> more complex ones, I use XML.) >>> >> As an individual (and not the chair of OAUTH) I believe that the server >> should be allowed, no encouraged, to support multiple formats for data >> retrieval. I also believe that clients should be allowed to choose only >> one. I am fine with JSON being Mandatory to Implement. I am NOT okay >> with making it the only one, and I am even less okay with mandating it >> is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- you >> can convince me either way) XML, and MAY for anything else that people >> feel stronly about (although I feel in 2012 XML and JSON are the two >> best). I also feel it is okay to say that a client MUST implement one >> of JSON or XML, and MAY implement more. >> >> >> > Why not MUST ASN.1 while you're at it? JSON has won in case > you'all haven't noticed it. > +1 Also bear in mind that when people say "XML" here, it's a specific subset of XML namely "application/xrd+xml". > Mike > > ______________________________**_________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/**listinfo/oauth > --20cf3071d0b66be78804be1d53e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 20 April 2012 16:40, Michael Thomas <= span dir=3D"ltr"><mike@mtcc.com>= wrote:
On 04/20/2012 07:17 AM, Derek Atkins wrote:
Paul,

"Paul E. Jones"<paulej@packetizer.com> =A0writes:

Tim,

I do not agree that it's harmful. If I removed the WF discussion off th= e
table, I'm still having a hard time buying into everything you said in = the
blog post.

I implement various web services, largely for my own use. =A0Usually, I
implement all of them in XML, JSON, plain text (attribute/value pairs), AND=
JavaScript (for JSONP). =A0For simple services, it's not hard. =A0I do = it
because I sometimes have different wants/desires on the client side. =A0(Fo= r
more complex ones, I use XML.)
As an individual (and not the chair of OAUTH) I believe that the server
should be allowed, no encouraged, to support multiple formats for data
retrieval. =A0I also believe that clients should be allowed to choose only<= br> one. =A0I am fine with JSON being Mandatory to Implement. =A0I am NOT okay<= br> with making it the only one, and I am even less okay with mandating it
is the ONLY one. =A0I would say MUST JSON, MUST (or possibly SHOULD -- you<= br> can convince me either way) XML, and MAY for anything else that people
feel stronly about (although I feel in 2012 XML and JSON are the two
best). =A0I also feel it is okay to say that a client MUST implement one of JSON or XML, and MAY implement more.



Why not MUST ASN.1 while you're at it? JSON has won in case
you'all haven't noticed it.

+1

Als= o bear in mind that when people say "XML" here, it's a specif= ic subset of XML namely "application/xrd+xml".=A0


Mike

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--20cf3071d0b66be78804be1d53e8-- From wmills@yahoo-inc.com Fri Apr 20 07:45:25 2012 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 7B1CF21F876D for ; Fri, 20 Apr 2012 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.123 X-Spam-Level: X-Spam-Status: No, score=-17.123 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJy8zHt5dYVA for ; Fri, 20 Apr 2012 07:45:24 -0700 (PDT) Received: from nm2.bullet.mail.sp2.yahoo.com (nm2.bullet.mail.sp2.yahoo.com [98.139.91.72]) by ietfa.amsl.com (Postfix) with SMTP id 2227E21F872B for ; Fri, 20 Apr 2012 07:45:24 -0700 (PDT) Received: from [98.139.91.66] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 20 Apr 2012 14:45:24 -0000 Received: from [98.139.91.10] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 20 Apr 2012 14:45:23 -0000 Received: from [127.0.0.1] by omp1010.mail.sp2.yahoo.com with NNFMP; 20 Apr 2012 14:45:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 909230.69380.bm@omp1010.mail.sp2.yahoo.com Received: (qmail 66981 invoked by uid 60001); 20 Apr 2012 14:45:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1334933123; bh=5RHkXY/BmJVZ7JLRRHQGc7cRREIIW+Cg2HZAwEat2kU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tZMTVgnUv+RRzNcXCUmeUY/JYVys5WTXvWWV5q04plGBBCmGz8e77XlPCKBvXe6fbj7tIOSPedlWI8p5FTcTLWvOSAT60TZN+cXV6F2pzQUMeBKNE70+wQmUi2hLP6lvmEq+sEaabZqiPjWfdhjjV5IWOp4zfg5vIKLSoCwTujc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=OovIvBJLbumVCatWVhVi0k8AEp1tpZYV1ye+EjCKDX/wNiy4qmpQyFGg+xs/M1+WbAAFwwHQc/uo5NyY0ytOCRLh9YslPtP480uZHKAa69rlNHrw8I46ckru28nQ45JpEf8AE72uFaieUt+ZA+VlXsop4Xt2boSl7B82vf4HJ5w=; X-YMail-OSG: LOjKxvkVM1kqXD5BDqKzbH2e8IalOMyIzPEHK2KJmFuQF14 MukCJ1Z_KjgicGtiUDSnWwLIZ8mld5jVrb2iNyCPaGpwoiwKJrJEOKm1_d6g Vu2TxOTNhp3tdGGdkQV3KsHbF7uuMPn_i.KJQo2Jl_4qG8Ad_YYvBYLpi1Re rRm9A8ZvXiHM9K59W34pw7RBX9USNDV5J4pNn6muSnZN_1wN777a2k1AC6By 7IpZOg_m.G2SrkiNh6Ih1E0FHeJIuh8yiz1UVmqZiuTdApT5WM3BrjNnugvV vCCKTe5n.xXiTMgyTxXS7l2ISvOnQ_r0_iLYbl865jTaaAb5f4e9mgPY1BAw P5MHgWXDANlNAgKkKWM52QKBfi_WlLP2Woq_wKSIT.M0X5ahsuW1NP1gR0MY ZDf360UN_MDBFqYtwNmc5cA.wTXFKvA-- Received: from [99.31.212.42] by web31803.mail.mud.yahoo.com via HTTP; Fri, 20 Apr 2012 07:45:23 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Fri, 20 Apr 2012 07:45:23 -0700 (PDT) From: William Mills To: Mike Jones , "Paul E. Jones" , "'Murray S. Kucherawy'" , "oauth@ietf.org" , 'Apps Discuss' In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-681895590-1334933123=:53510" Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 14:45:25 -0000 --1502656925-681895590-1334933123=:53510 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So you are guaranteeing that there are no clients using WF today?=A0 =0A=0A= =0A=0A=0A>________________________________=0A> From: Mike Jones =0A>To: Paul E. Jones ; 'Murray S.= Kucherawy' ; "oauth@ietf.org" ; 'Apps D= iscuss' =0A>Sent: Thursday, April 19, 2012 10:48 PM= =0A>Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discov= ery (SWD)=0A> =0A>To be clear, making this mandatory would break no clients= .=A0 It would require updating some servers, just as requiring JSON would.= =A0 This seems like a fair tradeoff when it makes an appreciable difference= in user interface latency in some important scenarios.=A0 If you and the o= ther key WebFinger supporters can agree to making "resource" support mandat= ory and requiring JSON, I believe we may have a path forward.=0A>=0A>=A0=A0= =A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Cheers,=0A>=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 -- Mike=0A>=0A>-----Original Message-----=0A>From: Paul E. Jones = [mailto:paulej@packetizer.com] =0A>Sent: Thursday, April 19, 2012 10:39 PM= =0A>To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'= =0A>Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discov= ery (SWD)=0A>=0A>That's correct.=A0 We could certainly make it mandatory, b= ut the reason it isn't is to maintain backward compatibility with existing = deployments.=0A>=0A>I think we should always think carefully when we decide= to make a change that breaks backward-compatibility.=A0 This is one change= that would do that.=0A>=0A>Paul=0A>=0A>> -----Original Message-----=0A>> F= rom: Mike Jones [mailto:Michael.Jones@microsoft.com]=0A>> Sent: Friday, Apr= il 20, 2012 1:10 AM=0A>> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ie= tf.org; 'Apps Discuss'=0A>> Subject: RE: [apps-discuss] [OAUTH-WG] Web Fing= er vs. Simple Web =0A>> Discovery=0A>> (SWD)=0A>> =0A>> Currently, support = for the "resource" parameter is optional, as per =0A>> the following (corre= ct?):=0A>> =0A>>=A0 =A0 Note that support for the "resource" parameter is o= ptional, but=0A>>=A0 =A0 strongly RECOMMENDED for improved performance.=A0 = If a server does not=0A>>=A0 =A0 implement the "resource" parameter, then t= he server's host metadata=0A>>=A0 =A0 processing logic remains unchanged fr= om RFC 6415.=0A>> =0A>> To truly support 1, this would need to be changed t= o REQUIRED, correct?=0A>> =0A>> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- = Mike=0A>> =0A>> -----Original Message-----=0A>> From: Paul E. Jones [mailto= :paulej@packetizer.com]=0A>> Sent: Thursday, April 19, 2012 8:16 PM=0A>> To= : Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'=0A>> Su= bject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web =0A>> Discov= ery=0A>> (SWD)=0A>> =0A>> Mike,=0A>> =0A>> > There are two criteria that I = would consider to be essential =0A>> > requirements for any resulting gener= al-purpose discovery specification:=0A>> >=0A>> > 1.=A0 Being able to alway= s discover per-user information with a single =0A>> > GET (minimizing user = interface latency for mobile devices, etc.)=0A>> =0A>> WF can do that.=A0 S= ee:=0A>> $ curl -v https://packetizer.com/.well-known/\=0A>>=A0 =A0 =A0 =A0= =A0 host-meta.json?resource=3Dacct:paulej@packetizer.com=0A>> =0A>> > 2.= =A0 JSON should be required and it should be the only format =0A>> > requir= ed (simplicity and ease of deployment/adoption)=0A>> =0A>> See the above ex= ample.=A0 However, I also support XML with my server.=A0 =0A>> It took me l= ess than 10 minutes to code up both XML and JSON representations.=0A>> Once= the requested format is determined, the requested URI is =0A>> determined,= data is pulled from the database, spitting out the desired =0A>> format is= trivial.=0A>> =0A>> Note, and very important note: supporting both XML and= JSON would only =0A>> be a server-side requirement.=A0 The client is at li= berty to use the =0A>> format it prefers.=A0 I would agree that forcing a c= lient to support =0A>> both would be unacceptable, but the server?=A0 Nothi= ng to it.=0A>> =0A>> > SWD already meets those requirements.=A0 If the resu= lting spec meets =0A>> > those requirements, it doesn't matter a lot whethe= r we call it =0A>> > WebFinger or Simple Web Discovery, but I believe that = the =0A>> > requirements discussion is probably the most productive one to = be =0A>> > having at this point - not the starting point document.=0A>> =0A= >> I believe WebFinger meets those requirements.=A0 We could debate whether= =0A>> XML should be supported, but I'll note (again) that it is there in R= FC 6415.=0A>> That document isn't all that old and, frankly, it concerns me= that we =0A>> would have a strong preference for format A one week and the= n Format B =0A>> the next.=0A>> We are where we are and I can see reason fo= r asking for JSON, but no =0A>> good reason to say we should not allow XML = (on the server side).=0A>> =0A>> Paul=0A>> =0A>> =0A>> =0A>=0A>=0A>=0A>=0A>= _______________________________________________=0A>OAuth mailing list=0A>OA= uth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A> --1502656925-681895590-1334933123=:53510 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So you are guaranteeing that there are no clients using WF today?  <= br>

From:<= /b> Mike Jones <Michael.Jones@microsoft.com>
To: Paul E. Jones <paulej@packetizer.com>= ;; 'Murray S. Kucherawy' <msk@cloudmark.com>; "oauth@ietf.org" <oa= uth@ietf.org>; 'Apps Discuss' <apps-discuss@ietf.org>
Sent: Thursday, April 19, 2012 10:= 48 PM
Subject: Re: [OA= UTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

To be clear, making this mandatory would break no clients.&nbs= p; It would require updating some servers, just as requiring JSON would.&nb= sp; This seems like a fair tradeoff when it makes an appreciable difference= in user interface latency in some important scenarios.  If you and th= e other key WebFinger supporters can agree to making "resource" support man= datory and requiring JSON, I believe we may have a path forward.

&nb= sp;               Ch= eers,
             &nb= sp;  -- Mike

-----Original Message-----
From: Paul E. Jones = [mailto:paulej@packetizer.com]
Sent:= Thursday, April 19, 2012 10:39 PM
To: Mike Jones; 'Murray S. Kucherawy'= ; oauth= @ietf.org; 'Apps Discuss'
Subject: RE: [apps-discuss] [OAUTH-WG] Web= Finger vs. Simple Web Discovery (SWD)

That's correct.  We coul= d certainly make it mandatory, but the reason it isn't is to maintain backw= ard compatibility with existing deployments.

I think we should alway= s think carefully when we decide to make a change that breaks backward-comp= atibility.  This is one change that would do that.

Paul

= > -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Friday, April 20, 2= 012 1:10 AM
> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@iet= f.org; 'Apps Discuss'
> Subject: RE: [apps-discuss] [OAUTH-WG] We= b Finger vs. Simple Web
> Discovery
> (SWD)
>
> C= urrently, support for the "resource" parameter is optional, as per
>= the following (correct?):
>
>    Note that support = for the "resource" parameter is optional, but
>    strongly= RECOMMENDED for improved performance.  If a server does not
>&n= bsp;   implement the "resource" parameter, then the server's host meta= data
>    processing logic remains unchanged from RFC 6415.=
>
> To truly support 1, this would need to be changed to REQU= IRED, correct?
>
>          = ;       -- Mike
>
> -----Original Mes= sage-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Thursday, April 19, 2012 8:16= PM
> To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discu= ss'
> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple We= b
> Discovery
> (SWD)
>
> Mike,
>
> = > There are two criteria that I would consider to be essential
> = > requirements for any resulting general-purpose discovery specification= :
> >
> > 1.  Being able to always discover per-user= information with a single
> > GET (minimizing user interface lat= ency for mobile devices, etc.)
>
> WF can do that.  See:<= br>> $ curl -v https://packetizer.com/.well-known/\
>    &= nbsp;     host-meta.json?resource=3Dacct:paulej@packetizer.com=
>
> > 2.  JSON should be required and it should b= e the only format
> > required (simplicity and ease of deployment= /adoption)
>
> See the above example.  However, I also su= pport XML with my server. 
> It took me less than 10 minutes to= code up both XML and JSON representations.
> Once the requested form= at is determined, the requested URI is
> determined, data is pulled = from the database, spitting out the desired
> format is trivial.
= >
> Note, and very important note: supporting both XML and JSON w= ould only
> be a server-side requirement.  The client is at lib= erty to use the
> format it prefers.  I would agree that forcin= g a client to support
> both would be unacceptable, but the server?  Nothing to it.
>
> > SWD already meets those= requirements.  If the resulting spec meets
> > those requir= ements, it doesn't matter a lot whether we call it
> > WebFinger = or Simple Web Discovery, but I believe that the
> > requirements = discussion is probably the most productive one to be
> > having a= t this point - not the starting point document.
>
> I believe = WebFinger meets those requirements.  We could debate whether
> = XML should be supported, but I'll note (again) that it is there in RFC 6415= .
> That document isn't all that old and, frankly, it concerns me tha= t we
> would have a strong preference for format A one week and then= Format B
> the next.
> We are where we are and I can see reas= on for asking for JSON, but no
> good reason to say we should not al= low XML (on the server side).
>
> Paul
>
>
>




_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/list= info/oauth


--1502656925-681895590-1334933123=:53510-- From tbray@textuality.com Fri Apr 20 08:12:14 2012 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 D407421F8730 for ; Fri, 20 Apr 2012 08:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5njDDbiENFF for ; Fri, 20 Apr 2012 08:12:14 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5FCB21F875B for ; Fri, 20 Apr 2012 08:12:13 -0700 (PDT) Received: by yhkk25 with SMTP id k25so5979474yhk.31 for ; Fri, 20 Apr 2012 08:12:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=XEDLJ0XtvEUOTF03zrcECRBYf36DRhPQ93V57QhHpu4=; b=aLE15l/b1bXNu1KSleOEgPkchc2hD33fLhopd9oojgJ4MZybyS5wgMPPeJTecWo7ih yDU2ZAsNxv6OKDySoXXc0dvhoV4tupLmVY3pZ1wKyhnOS0Z1rlyXtttB168fBRK1UD34 QzdFhieHBvr4jwCtXpUaLSEzSQN2OcgQKqdNnMxVd2gJevXgheGU+bIYt6LwxSh1pn65 Tpau0yhi69Ud5+kKCjwc7E6Gv5Brm/w34bVUV0R1O2DtlL5PD5jRx3L6xK5IL5fbr70p mesk17TkINQTbETOyYFZik2OO0bBwczv/nO0IKdVFxkTbOOgldCRMFY/+9l4qm6tvRjE b7xg== MIME-Version: 1.0 Received: by 10.60.0.196 with SMTP id 4mr9397405oeg.0.1334934733294; Fri, 20 Apr 2012 08:12:13 -0700 (PDT) Received: by 10.182.204.71 with HTTP; Fri, 20 Apr 2012 08:12:13 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> Date: Fri, 20 Apr 2012 08:12:13 -0700 Message-ID: From: Tim Bray To: Derek Atkins Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn6RFjM64VMkVr0J2FUr7fEzoBL64hL8SJXGnlnD5FBUqQq6bAJ13ExCyXc3gtXMUGo1P+7 Cc: oauth@ietf.org, Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 15:12:15 -0000 There's a disconnect here. Mnot and I (at least) have argued that there are very specific problems and costs associated with going multi-format. I=92ve heard lots of people say "Well, I support multi-format=94 but I haven=92t heard any specific responses explaining why those costs and problems aren=92t real, or why the benefits are sufficiently great that we should just accept them. Mnot: JSON or XML: Just Decide http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide tbray: Case Study: Atom and/or JSON http://www.tbray.org/ongoing/When/200x/2009/04/29/Model-and-Syntax#p-1 Would this work better if I summarized the problems here inline in this thread? It may be the pace that people=92s IETF/email workflow is such that they=92re not able comfortably to consult external references? -Tim On Fri, Apr 20, 2012 at 7:17 AM, Derek Atkins wrote: > Paul, > > "Paul E. Jones" writes: > >> Tim, >> >> I do not agree that it's harmful. If I removed the WF discussion off the >> table, I'm still having a hard time buying into everything you said in t= he >> blog post. >> >> I implement various web services, largely for my own use. =A0Usually, I >> implement all of them in XML, JSON, plain text (attribute/value pairs), = AND >> JavaScript (for JSONP). =A0For simple services, it's not hard. =A0I do i= t >> because I sometimes have different wants/desires on the client side. =A0= (For >> more complex ones, I use XML.) > > As an individual (and not the chair of OAUTH) I believe that the server > should be allowed, no encouraged, to support multiple formats for data > retrieval. =A0I also believe that clients should be allowed to choose onl= y > one. =A0I am fine with JSON being Mandatory to Implement. =A0I am NOT oka= y > with making it the only one, and I am even less okay with mandating it > is the ONLY one. =A0I would say MUST JSON, MUST (or possibly SHOULD -- yo= u > can convince me either way) XML, and MAY for anything else that people > feel stronly about (although I feel in 2012 XML and JSON are the two > best). =A0I also feel it is okay to say that a client MUST implement one > of JSON or XML, and MAY implement more. > > > > Note that this is a replay of the historical "MUST Implement" versus > "MUST Use" arguments. =A0Just because the server MUST IMPLEMENT JSON and > XML does not mean that a Client must use both (or even that a client > must implement both). =A0It is perfectly reasonable and generally > acceptable to have a server that provides data in multiple formats > whereas the client only supports a subset and specifies which format(s) > are acceptable. > > > > -derek > > -- > =A0 =A0 =A0 Derek Atkins =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 617-623-3745 > =A0 =A0 =A0 derek@ihtfp.com =A0 =A0 =A0 =A0 =A0 =A0 www.ihtfp.com > =A0 =A0 =A0 Computer and Internet Security Consultant From mike@mtcc.com Fri Apr 20 08:12:48 2012 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 F21F421F87B9; Fri, 20 Apr 2012 08:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpmiMAoPEkvz; Fri, 20 Apr 2012 08:12:45 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 66EF421F87A5; Fri, 20 Apr 2012 08:12:45 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3KFCcFx024031 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 Apr 2012 08:12:38 -0700 Message-ID: <4F917CE6.2060904@mtcc.com> Date: Fri, 20 Apr 2012 08:12:38 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Derek Atkins References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1149; t=1334934759; x=1335798759; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20[apps-discuss]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Derek=20Atkins=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=gumPh5+dRN4yReAgLh6SWnugtflqzOpFSFW6RL+cqfw=; b=fdI4Qsoh6z0Jv9Xg4oOqQeQgYUhDIDaWrdy1YtNAASkKvnkS3MSi+fiZSl XOT+cRNl8vsrP/SjtPSSKrSKyjwLPyJCaY9Z20U5dseF0vfXR7crjB8Sj6fB ZrfdW0TOujLrZjBbNekx0ip1S1x1cloL4YByVHqCq9clQ8etcOZlo=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: 'Tim Bray' , oauth@ietf.org, 'Apps Discuss' Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 15:12:49 -0000 On 04/20/2012 07:17 AM, Derek Atkins wrote: > Note that this is a replay of the historical "MUST Implement" versus "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON and XML does not mean that a Client must use both (or even that a client must implement both). It is perfectly reasonable and generally acceptable to have a server that provides data in multiple formats whereas the client only supports a subset and specifies which format(s) are acceptable. -derek To Paul's point about how easy it is for a server to support both, I'd retort that it's equally easy for a client to gin up JSON instead of XML. Pity the poor programmer who can't get their head around that gigantic change. On the other hand, having to support XML and JSON is an ongoing maintenance headache server-side. Why do it? There isn't even the dubious religious war like back in the day saying that binary encoded ASN.1 was "better/faster/stacks and cleans dishes" than "human readable" XML. XML is just a clunky and past its prime text encoding at this point. Requiring it smacks of nostalgia to me. Mike From ve7jtb@ve7jtb.com Fri Apr 20 08:12:49 2012 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 F214F21F87BD for ; Fri, 20 Apr 2012 08:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9KjE57z5cPZ for ; Fri, 20 Apr 2012 08:12:45 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 84DC021F8786 for ; Fri, 20 Apr 2012 08:12:35 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so6616680wgb.13 for ; Fri, 20 Apr 2012 08:12:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=QfY2UKM7Xfy9xfvybU6+wIXoda53e/iQoIvFqUH+0OY=; b=HjaJCbhZIuZbXK9uumRwRHVrovSglp7znv0+PoqsrTQIv7wo6vn9CJfesS6VMsPGWA 5+HvtBeCIVHkL9bDMueDj6TvTasjkfc62nsKkg5AveFx+67nDRMnW96J9Tj3TAPSSijF yrbd/w0ZbuzgqFRBOOjQisyNtsGYkbzFxBzJrDHFP7ws4mWpYBJ1xZh2UltZ1JXxsmg8 vmAtlzr1P9KaEyPZiCx4peGFYtXiwTNYSQdknv6YepAQ4uZnOqJ25hl/FLmPCRIT7neH izrJir3YMwoiAONuVDMqPlmlbXNsguWx3pvNiMFI2k2JpcX70wdkDw29xsJEkL6pECp0 GhNg== Received: by 10.216.137.30 with SMTP id x30mr3888264wei.34.1334934754555; Fri, 20 Apr 2012 08:12:34 -0700 (PDT) Received: from [10.140.224.153] ([80.187.201.110]) by mx.google.com with ESMTPS id fl2sm9696842wib.2.2012.04.20.08.12.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Apr 2012 08:12:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_9809CEA2-8BA2-410F-97F7-5AAC15EBD820"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Fri, 20 Apr 2012 17:12:23 +0200 Message-Id: References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkJJruE41Dj2sqYlJuCCpwuap5bVkifcCyOJHb2A/TAxr0xPi7cvbbefCWJ5nIk49OgXieX Cc: "oauth@ietf.org" , 'Apps Discuss' Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 15:12:49 -0000 --Apple-Mail=_9809CEA2-8BA2-410F-97F7-5AAC15EBD820 Content-Type: multipart/alternative; boundary="Apple-Mail=_5AF5B7AE-5CDC-4812-BEF4-B1F65C6F129F" --Apple-Mail=_5AF5B7AE-5CDC-4812-BEF4-B1F65C6F129F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 We are not arguing that XML be removed from the server. Only that JSON = be mandatory for the server to support. Others on the list piled on the removing XML argument. =20 I do think there is a legitimate argument that fewer options make for = better interoperability. However Mike and myself are not the ones making that argument. Only that the server MUST support JSON. The other MUST Mike had was getting the JRD with a single get and not = needing to retrieve the host-meta file first to retrieve the template. That is probably the largest design difference. SWD uses a .well-known location as effectively a static template and = only redirects if necessary. Where as Web Finger assumes the overhead of one extra GET on the first = request to add a configurable template. one compromise and perhaps not the best is to leave the current = host-meta mechanism. Add a new SWD endpoint (fixed-template) in .well-known that provides the = service, or is an alias for the host-mata file. A client could try the SWD endpoint (fixed template first and get a = response in one go, or get back a host meta file and take the template = from that and try again. A redirect might be better as that could be cached. ( open to debate) That would make the happy path discovery for web-finger be one GET and = possibly some people happy. The existing clients would get .well known and get the template as they = do now. The single GET could be considered an optimization. If we pick off the issues one at a time I hope we can find solutions. John B. On 2012-04-20, at 4:45 PM, William Mills wrote: > So you are guaranteeing that there are no clients using WF today? =20 >=20 > From: Mike Jones > To: Paul E. Jones ; 'Murray S. Kucherawy' = ; "oauth@ietf.org" ; 'Apps Discuss' = =20 > Sent: Thursday, April 19, 2012 10:48 PM > Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web = Discovery (SWD) >=20 > To be clear, making this mandatory would break no clients. It would = require updating some servers, just as requiring JSON would. This seems = like a fair tradeoff when it makes an appreciable difference in user = interface latency in some important scenarios. If you and the other key = WebFinger supporters can agree to making "resource" support mandatory = and requiring JSON, I believe we may have a path forward. >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com]=20 > Sent: Thursday, April 19, 2012 10:39 PM > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web = Discovery (SWD) >=20 > That's correct. We could certainly make it mandatory, but the reason = it isn't is to maintain backward compatibility with existing = deployments. >=20 > I think we should always think carefully when we decide to make a = change that breaks backward-compatibility. This is one change that = would do that. >=20 > Paul >=20 > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Friday, April 20, 2012 1:10 AM > > To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss' > > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 > > Discovery > > (SWD) > >=20 > > Currently, support for the "resource" parameter is optional, as per=20= > > the following (correct?): > >=20 > > Note that support for the "resource" parameter is optional, but > > strongly RECOMMENDED for improved performance. If a server does = not > > implement the "resource" parameter, then the server's host = metadata > > processing logic remains unchanged from RFC 6415. > >=20 > > To truly support 1, this would need to be changed to REQUIRED, = correct? > >=20 > > -- Mike > >=20 > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Thursday, April 19, 2012 8:16 PM > > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss' > > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web=20 > > Discovery > > (SWD) > >=20 > > Mike, > >=20 > > > There are two criteria that I would consider to be essential=20 > > > requirements for any resulting general-purpose discovery = specification: > > > > > > 1. Being able to always discover per-user information with a = single=20 > > > GET (minimizing user interface latency for mobile devices, etc.) > >=20 > > WF can do that. See: > > $ curl -v https://packetizer.com/.well-known/\ > > host-meta.json?resource=3Dacct:paulej@packetizer.com > >=20 > > > 2. JSON should be required and it should be the only format=20 > > > required (simplicity and ease of deployment/adoption) > >=20 > > See the above example. However, I also support XML with my server. =20= > > It took me less than 10 minutes to code up both XML and JSON = representations. > > Once the requested format is determined, the requested URI is=20 > > determined, data is pulled from the database, spitting out the = desired=20 > > format is trivial. > >=20 > > Note, and very important note: supporting both XML and JSON would = only=20 > > be a server-side requirement. The client is at liberty to use the=20= > > format it prefers. I would agree that forcing a client to support=20= > > both would be unacceptable, but the server? Nothing to it. > >=20 > > > SWD already meets those requirements. If the resulting spec meets=20= > > > those requirements, it doesn't matter a lot whether we call it=20 > > > WebFinger or Simple Web Discovery, but I believe that the=20 > > > requirements discussion is probably the most productive one to be=20= > > > having at this point - not the starting point document. > >=20 > > I believe WebFinger meets those requirements. We could debate = whether=20 > > XML should be supported, but I'll note (again) that it is there in = RFC 6415. > > That document isn't all that old and, frankly, it concerns me that = we=20 > > would have a strong preference for format A one week and then Format = B=20 > > the next. > > We are where we are and I can see reason for asking for JSON, but no=20= > > good reason to say we should not allow XML (on the server side). > >=20 > > Paul > >=20 > >=20 > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5AF5B7AE-5CDC-4812-BEF4-B1F65C6F129F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 We = are not arguing that XML be removed from the server.  Only that = JSON be mandatory for the server to support.

Others = on the list piled on the removing XML argument. =   

I do think there is a legitimate = argument that fewer options make for better = interoperability.

However Mike and myself are = not the ones making that argument.

Only that = the server MUST support JSON.

The other MUST = Mike had was getting the JRD with a single get and not needing to = retrieve the host-meta file first to retrieve the = template.

That is probably the largest design = difference.

SWD uses a .well-known location as = effectively a static template and only redirects if = necessary.

Where as Web Finger assumes the = overhead of one extra GET on the first request to add a configurable = template.

one compromise and perhaps not the = best is to leave the current host-meta mechanism.
Add a new = SWD endpoint (fixed-template) in .well-known that provides the service, = or is an alias for the host-mata file.

A client = could try the SWD endpoint (fixed template first and get a response in = one go, or get back a  host meta file and take the template from = that and try again.

A redirect might be better = as that could be cached. ( open to debate)

That = would make the happy path discovery for web-finger be one GET and = possibly some people happy.

The existing = clients would get .well known and get the template as they do = now.

The single GET could be considered an = optimization.

If we pick off the issues one at = a time I hope we can find solutions.

John = B.
On 2012-04-20, at 4:45 PM, William Mills = wrote:

So you are guaranteeing that there = are no clients using WF today?  =

From: Mike Jones <Michael.Jones@microsoft.com>
To: Paul E. = Jones <paulej@packetizer.com>; = 'Murray S. Kucherawy' <msk@cloudmark.com>; "oauth@ietf.org" <oauth@ietf.org>; 'Apps Discuss' = <apps-discuss@ietf.org>=
Sent: Thursday, = April 19, 2012 10:48 PM
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. = Simple Web Discovery (SWD)

To be clear, making = this mandatory would break no clients.  It would require updating = some servers, just as requiring JSON would.  This seems like a fair = tradeoff when it makes an appreciable difference in user interface = latency in some important scenarios.  If you and the other key = WebFinger supporters can agree to making "resource" support mandatory = and requiring JSON, I believe we may have a path = forward.

            =     Cheers,
        =         -- Mike

-----Original = Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com] =
Sent: Thursday, April 19, 2012 10:39 PM
To: Mike Jones; 'Murray = S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss'
Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple = Web Discovery (SWD)

That's correct.  We could certainly make = it mandatory, but the reason it isn't is to maintain backward = compatibility with existing deployments.

I think we should always = think carefully when we decide to make a change that breaks = backward-compatibility.  This is one change that would do = that.

Paul

> -----Original Message-----
> From: = Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Friday, April 20, 2012 1:10 AM
> To: Paul E. = Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss'
> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. = Simple Web
> Discovery
> (SWD)
>
> Currently, = support for the "resource" parameter is optional, as per
> the = following (correct?):
>
>    Note that support = for the "resource" parameter is optional, but
>    = strongly RECOMMENDED for improved performance.  If a server does = not
>    implement the "resource" parameter, then the = server's host metadata
>    processing logic remains = unchanged from RFC 6415.
>
> To truly support 1, this would = need to be changed to REQUIRED, correct?
>
> =             =     -- Mike
>
> -----Original = Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> = Sent: Thursday, April 19, 2012 8:16 PM
> To: Mike Jones; 'Murray = S. Kucherawy'; oauth@ietf.org; 'Apps = Discuss'
> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. = Simple Web
> Discovery
> (SWD)
>
> = Mike,
>
> > There are two criteria that I would consider = to be essential
> > requirements for any resulting = general-purpose discovery specification:
> >
> > = 1.  Being able to always discover per-user information with a = single
> > GET (minimizing user interface latency for mobile = devices, etc.)
>
> WF can do that.  See:
> $ = curl -v https://packetizer.com/.well-known/\
>  =         host-meta.json?resource=3Dacct:paulej@packetizer.com
> =
> > 2.  JSON should be required and it should be the only = format
> > required (simplicity and ease of = deployment/adoption)
>
> See the above example.  = However, I also support XML with my server. 
> It took me = less than 10 minutes to code up both XML and JSON = representations.
> Once the requested format is determined, the = requested URI is
> determined, data is pulled from the database, = spitting out the desired
> format is trivial.
>
> = Note, and very important note: supporting both XML and JSON would only =
> be a server-side requirement.  The client is at liberty to = use the
> format it prefers.  I would agree that forcing a = client to support
> both would be unacceptable, but the server?  Nothing to it.
>
> > SWD already meets = those requirements.  If the resulting spec meets
> > = those requirements, it doesn't matter a lot whether we call it
> = > WebFinger or Simple Web Discovery, but I believe that the
> = > requirements discussion is probably the most productive one to be =
> > having at this point - not the starting point = document.
>
> I believe WebFinger meets those = requirements.  We could debate whether
> XML should be = supported, but I'll note (again) that it is there in RFC 6415.
> = That document isn't all that old and, frankly, it concerns me that we =
> would have a strong preference for format A one week and then = Format B
> the next.
> We are where we are and I can see = reason for asking for JSON, but no
> good reason to say we should = not allow XML (on the server side).
>
> Paul
> =
>
> =




_______________________________________________
OAu= th mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_5AF5B7AE-5CDC-4812-BEF4-B1F65C6F129F-- --Apple-Mail=_9809CEA2-8BA2-410F-97F7-5AAC15EBD820 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy MDE1MTIyNFowIwYJKoZIhvcNAQkEMRYEFOb8elBHYZycKYE2GdEGeOb9JN55MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACYGed00oUEnCA9KbimsVjdvuAt1ArGWZznyhWWIaxvnIw6k/AH10/P8SbUsDWOlRmejudDmA+Mz 5q9LtRBGIxlklfMSzgaeJSa9bcI6z+Lv0bsTCuwowpnLC8WQ4G4lA6U1TvG1/L7jgM6lIMh0H3YH i9vQ7XarAnuc0G27F18OGe3cDPIV0K+/jVM8BskHQVekdV7YKdqHgYb68YTHFg1ERpCXsLS54T1y pLInlIt8sG3Rk0FILwgh7oE4Hj/zDulHSX8AGzLcN7MUYsSWMf5C+Dk1gXMvBXuET5DyqcxuMD2e Cl1VUNAvQT3mZkAj6hMzE7BV8RZCuHRYPXzwHAoAAAAAAAA= --Apple-Mail=_9809CEA2-8BA2-410F-97F7-5AAC15EBD820-- From julian.reschke@gmx.de Fri Apr 20 08:31:29 2012 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 9541521F8772 for ; Fri, 20 Apr 2012 08:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCNK586l+F9z for ; Fri, 20 Apr 2012 08:31:28 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 36C6221F8744 for ; Fri, 20 Apr 2012 08:31:27 -0700 (PDT) Received: (qmail invoked by alias); 20 Apr 2012 15:31:26 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.83]) [217.91.35.233] by mail.gmx.net (mp072) with SMTP; 20 Apr 2012 17:31:26 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/vvuZqBdzv5ovy1dM/FBl0QXdF4jCzKY0pnOttpt zdGATuUleEperd Message-ID: <4F91814A.2010606@gmx.de> Date: Fri, 20 Apr 2012 17:31:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Michael Thomas References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <4F917CE6.2060904@mtcc.com> In-Reply-To: <4F917CE6.2060904@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Derek Atkins , oauth@ietf.org, 'Apps Discuss' Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 15:31:29 -0000 On 2012-04-20 17:12, Michael Thomas wrote: > ... > To Paul's point about how easy it is for a server to support both, I'd > retort that it's equally easy for a client to gin up JSON instead of XML. > Pity the poor programmer who can't get their head around that gigantic > change. On the other hand, having to support XML and JSON is an ongoing > maintenance headache server-side. Why do it? There isn't even the dubious > religious war like back in the day saying that binary encoded ASN.1 was > "better/faster/stacks and cleans dishes" than "human readable" XML. XML > is just a clunky and past its prime text encoding at this point. > Requiring it > smacks of nostalgia to me. > ... What's sure is that with generalizations like these, you're not going to convince anybody. JSON is simpler than XML. Sometimes it's too simple. In my experience, testing HTTP interfaces that return XML is more pleasant as a browser will actually *display* the response (and allow it to be transformed to HTML client-side), while it will pop up a download dialogue for application/json. Maybe it's time to fix the latter? Best regards, Julian From mike@mtcc.com Fri Apr 20 08:51:29 2012 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 9265C21F86D3; Fri, 20 Apr 2012 08:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkVDVBpurCip; Fri, 20 Apr 2012 08:51:28 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 96ABE21F86DE; Fri, 20 Apr 2012 08:51:28 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3KFpO3K007622 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 Apr 2012 08:51:24 -0700 Message-ID: <4F9185FC.5070406@mtcc.com> Date: Fri, 20 Apr 2012 08:51:24 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Julian Reschke References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <4F917CE6.2060904@mtcc.com> <4F91814A.2010606@gmx.de> In-Reply-To: <4F91814A.2010606@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2157; t=1334937085; x=1335801085; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[apps-discuss]=20[OAUTH-WG]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Julian=20Reschke=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=r4kkUgFtrRlHis/kPLyKpWArS9X6s1F9WzHt/vb/m+k=; b=JvNfuNtRTPZYMlJU3413YfQUZeQcA8zf7oS7wob/JSGzokHCBZ3OW9agBS Hqu4PRLCcxh/rtUduDNxUnoY0UirJVurirRnZp2E0T+KQyIxj5Emz07lT8vs xqXrY6LrFDSKeDc9uo0NTnB16VM/iIXKwyj6mttE2SIPeo1PGVspE=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Derek Atkins , oauth@ietf.org, 'Apps Discuss' Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 15:51:29 -0000 On 04/20/2012 08:31 AM, Julian Reschke wrote: > On 2012-04-20 17:12, Michael Thomas wrote: >> ... >> To Paul's point about how easy it is for a server to support both, I'd >> retort that it's equally easy for a client to gin up JSON instead of XML. >> Pity the poor programmer who can't get their head around that gigantic >> change. On the other hand, having to support XML and JSON is an ongoing >> maintenance headache server-side. Why do it? There isn't even the dubious >> religious war like back in the day saying that binary encoded ASN.1 was >> "better/faster/stacks and cleans dishes" than "human readable" XML. XML >> is just a clunky and past its prime text encoding at this point. >> Requiring it >> smacks of nostalgia to me. >> ... > > What's sure is that with generalizations like these, you're not going to convince anybody. > > JSON is simpler than XML. Sometimes it's too simple. > > In my experience, testing HTTP interfaces that return XML is more pleasant as a browser will actually *display* the response (and allow it to be transformed to HTML client-side), while it will pop up a download dialogue for application/json. Maybe it's time to fix the latter? > It may be a generalization, but it's based on direct experience. I create and use JSON for fairly complex data structures transferred server->client (it's a ski tracking app) and I have never once thought "gosh, I wish that I had the expressiveness of XML here". On the input side of uploading points to the server, I use a home grown XML scheme purely for my own historical reasons and I do often wish that I could get rid of it. The worst of all possible worlds would be to require support for both on the input and output side. Bletch. Just the testing requirements would be onerous. I also know that, oh say, twitter supports XML and JSON in their API. Probably lots of companies do. I'll bet if you asked them now, they'd say they wish they hadn't supported XML at this point because it's nothing more than overhead, keeping some dev and devtest folks gainfully employed. Mike, and I don't have a problem viewing JSON in a browser From gsalguei@cisco.com Fri Apr 20 10:09:51 2012 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 326AC21F86F0 for ; Fri, 20 Apr 2012 10:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fueeFK0X4mDa for ; Fri, 20 Apr 2012 10:09:50 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 23F9D21F86EA for ; Fri, 20 Apr 2012 10:09:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3KH9mxK018509 for ; Fri, 20 Apr 2012 13:09:48 -0400 (EDT) Received: from dhcp-64-102-154-162.cisco.com (dhcp-64-102-154-162.cisco.com [64.102.154.162]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3KH9mLD004542; Fri, 20 Apr 2012 13:09:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: Date: Fri, 20 Apr 2012 13:09:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> To: Derek Atkins X-Mailer: Apple Mail (2.1257) Cc: oauth@ietf.org, Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 17:09:51 -0000 Derek -=20 On Apr 20, 2012, at 10:17 AM, Derek Atkins wrote: > Paul, >=20 > "Paul E. Jones" writes: >=20 >> Tim, >>=20 >> I do not agree that it's harmful. If I removed the WF discussion off = the >> table, I'm still having a hard time buying into everything you said = in the >> blog post. >>=20 >> I implement various web services, largely for my own use. Usually, I >> implement all of them in XML, JSON, plain text (attribute/value = pairs), AND >> JavaScript (for JSONP). For simple services, it's not hard. I do it >> because I sometimes have different wants/desires on the client side. = (For >> more complex ones, I use XML.) >=20 > As an individual (and not the chair of OAUTH) I believe that the = server > should be allowed, no encouraged, to support multiple formats for data > retrieval. I also believe that clients should be allowed to choose = only > one. I am fine with JSON being Mandatory to Implement. I am NOT okay > with making it the only one, and I am even less okay with mandating it > is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- = you > can convince me either way) XML, and MAY for anything else that people > feel stronly about (although I feel in 2012 XML and JSON are the two > best). I also feel it is okay to say that a client MUST implement one > of JSON or XML, and MAY implement more. >=20 > >=20 > Note that this is a replay of the historical "MUST Implement" versus > "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON and > XML does not mean that a Client must use both (or even that a client > must implement both). It is perfectly reasonable and generally > acceptable to have a server that provides data in multiple formats > whereas the client only supports a subset and specifies which = format(s) > are acceptable. >=20 > >=20 This is the most sensible path forward. A MUST for JSON and XML (I'm = going with a MUST for XML to maintain backwards compatibility with RFC = 6415) on the server side and a client can choose whatever format it = wants. This is the approach taken in the current WebFinger draft. If we = reach consensus that we must mandate a client format (Note: I don't = personally think we need to), then so be it. Cheers, Gonzalo > -derek >=20 > --=20 > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From ve7jtb@ve7jtb.com Fri Apr 20 10:23:17 2012 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 100B621F84D6 for ; Fri, 20 Apr 2012 10:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhBsNZwIOPJ2 for ; Fri, 20 Apr 2012 10:23:16 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2C0021F84CD for ; Fri, 20 Apr 2012 10:23:15 -0700 (PDT) Received: by werb10 with SMTP id b10so7650853wer.31 for ; Fri, 20 Apr 2012 10:23:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=etiJOJpNjoXe52drxGhqUZ4L+p51A0a3MwpL08du11M=; b=lu5p+IIXaC15qbvG/Rza2+lzUgHNkc+0yHlVEWEbFZcsf2wTyoN5u7MG+RVmwAE/Zp 2jUcSSRzsXvbCU7k/ngKrDXdZ3MIzq95wJ0cYFA38PIuJBA2GAFiPXDe/0uJXtxY1mas m58ghcapSuVSn6VIycR/8ANlqBLlglUeDtMWBmjbCI7UE4j1zlxjCzLfbB8epX1CghLe TrIm4saC3fmkCtds2f9y0h9Hp5P2+qmGO6xECJAtdg4HI/qI0V040+bStyrPO0Xm/jzS XYFAhLqrX7Z8OaU4aUXattUJxzp0wbW1BbVLFZq9ZSEOh1cpdhD0NlRQOopOqeWa1NdB nQsw== Received: by 10.180.105.194 with SMTP id go2mr16941696wib.22.1334942592921; Fri, 20 Apr 2012 10:23:12 -0700 (PDT) Received: from [10.140.224.153] ([80.187.201.110]) by mx.google.com with ESMTPS id fz9sm6854920wib.3.2012.04.20.10.23.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Apr 2012 10:23:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_4D87D0D9-2D96-435C-9F60-A10949B3666A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com> Date: Fri, 20 Apr 2012 19:23:06 +0200 Message-Id: <1BE3A02A-7287-4401-8B73-366390CB3676@ve7jtb.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com> To: Gonzalo Salgueiro X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmabno3NMZgeXksbONTK37EptoyzSpMRNPPIvkHU1mhQrt4EfRHhLHPY5Gywah3siXyhBXX Cc: Derek Atkins , oauth@ietf.org, Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 17:23:17 -0000 --Apple-Mail=_4D87D0D9-2D96-435C-9F60-A10949B3666A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would be OK with optional XML support in the server, that way = existing endpoints will continue to work, but new ones are not required = to add something some people feel is cruft. As one of the XRD authors, I do understand the advantages of it. However I don't want to be sentimental, and force people to carry = forward things that won't be used, and may hamper adoption. And Yes I am one of the hard hatred basters that decided to redo openID = on OAuth rather than trying to graft OAuth functionality onto openID 2. = =20 Keeping what's working working is fine, but not forcing people to carry = it forward. John B. On 2012-04-20, at 7:09 PM, Gonzalo Salgueiro wrote: > Derek -=20 >=20 > On Apr 20, 2012, at 10:17 AM, Derek Atkins wrote: >=20 >> Paul, >>=20 >> "Paul E. Jones" writes: >>=20 >>> Tim, >>>=20 >>> I do not agree that it's harmful. If I removed the WF discussion off = the >>> table, I'm still having a hard time buying into everything you said = in the >>> blog post. >>>=20 >>> I implement various web services, largely for my own use. Usually, = I >>> implement all of them in XML, JSON, plain text (attribute/value = pairs), AND >>> JavaScript (for JSONP). For simple services, it's not hard. I do = it >>> because I sometimes have different wants/desires on the client side. = (For >>> more complex ones, I use XML.) >>=20 >> As an individual (and not the chair of OAUTH) I believe that the = server >> should be allowed, no encouraged, to support multiple formats for = data >> retrieval. I also believe that clients should be allowed to choose = only >> one. I am fine with JSON being Mandatory to Implement. I am NOT = okay >> with making it the only one, and I am even less okay with mandating = it >> is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- = you >> can convince me either way) XML, and MAY for anything else that = people >> feel stronly about (although I feel in 2012 XML and JSON are the two >> best). I also feel it is okay to say that a client MUST implement = one >> of JSON or XML, and MAY implement more. >>=20 >> >>=20 >> Note that this is a replay of the historical "MUST Implement" versus >> "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON = and >> XML does not mean that a Client must use both (or even that a client >> must implement both). It is perfectly reasonable and generally >> acceptable to have a server that provides data in multiple formats >> whereas the client only supports a subset and specifies which = format(s) >> are acceptable. >>=20 >> >>=20 >=20 > This is the most sensible path forward. A MUST for JSON and XML (I'm = going with a MUST for XML to maintain backwards compatibility with RFC = 6415) on the server side and a client can choose whatever format it = wants. This is the approach taken in the current WebFinger draft. If we = reach consensus that we must mandate a client format (Note: I don't = personally think we need to), then so be it. >=20 > Cheers, >=20 > Gonzalo >=20 >> -derek >>=20 >> --=20 >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4D87D0D9-2D96-435C-9F60-A10949B3666A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy MDE3MjMwOFowIwYJKoZIhvcNAQkEMRYEFIiZAm+jiMEDvIdzGgYmiCaMZruoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AAY08T4KttHcJve+xN184vf881siorKcuXOLal3tE2sHF5snCIfXctDakqKf6sblVgjCu6SMt5ma W1YLMZZzPEdsKyz97svgdxjYvMqF64y+MYz6W0H0Vva1MZz6skynHpcRF7n6hsYwzr8F0Lu9VV6Z bIuotFAfLsHtgC1h/nknkzlUk0TNmVPIRZ744nNFdQ6GSZdTLhybblkIMvxdIT9d1qfNBxKUIjq4 gnIDkGdupkrdQ7FrqakKpjslUI+2+yESr9sixie54dcCbKpfmid7w8w18Q05fvRe2KsTnyGOwKwB hJRbFBzK/sZtZ6gU9wRLqDR7BSYOvn7pKxxOm+UAAAAAAAA= --Apple-Mail=_4D87D0D9-2D96-435C-9F60-A10949B3666A-- From gsalguei@cisco.com Fri Apr 20 10:34:43 2012 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 48D6D21F866D for ; Fri, 20 Apr 2012 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ohj1z-gzfRgO for ; Fri, 20 Apr 2012 10:34:42 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 54A3E21F864D for ; Fri, 20 Apr 2012 10:34:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3KHYfqa021097 for ; Fri, 20 Apr 2012 13:34:41 -0400 (EDT) Received: from dhcp-64-102-154-162.cisco.com (dhcp-64-102-154-162.cisco.com [64.102.154.162]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3KHYfiv001935; Fri, 20 Apr 2012 13:34:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <1BE3A02A-7287-4401-8B73-366390CB3676@ve7jtb.com> Date: Fri, 20 Apr 2012 13:34:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <379ABFA6-E78C-4CD4-B7F7-6E0EC452DF74@cisco.com> References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com> <1BE3A02A-7287-4401-8B73-366390CB3676@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1257) Cc: Derek Atkins , oauth@ietf.org, Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 17:34:43 -0000 John -=20 I understand your position, I truly do. I'd even go so far as saying = that a part of me agree with you given the ubiquitousness of JSON. Two = concerns/questions come to mind: - If it is a MUST in 6415, then isn't it simply good protocol design to = maintain that same level of requirement in the discovery protocol based = entirely on it? If the answer is "no", then we can figure something out = but I'm sharing that this was our primary motivation for requiring it in = WebFinger. - Is it alarming to anyone how quickly we go through "flavor of the day" = formats? 6415 was published 6 months ago and we are already ready to = declare the mandatory format there a dinosaur that is now obsolete and = unnecessary? Cheers, Gonzalo On Apr 20, 2012, at 1:23 PM, John Bradley wrote: > I would be OK with optional XML support in the server, that way = existing endpoints will continue to work, but new ones are not required = to add something some people feel is cruft. >=20 > As one of the XRD authors, I do understand the advantages of it. >=20 > However I don't want to be sentimental, and force people to carry = forward things that won't be used, and may hamper adoption. >=20 > And Yes I am one of the hard hatred basters that decided to redo = openID on OAuth rather than trying to graft OAuth functionality onto = openID 2. =20 >=20 > Keeping what's working working is fine, but not forcing people to = carry it forward. >=20 > John B. >=20 > On 2012-04-20, at 7:09 PM, Gonzalo Salgueiro wrote: >=20 >> Derek -=20 >>=20 >> On Apr 20, 2012, at 10:17 AM, Derek Atkins wrote: >>=20 >>> Paul, >>>=20 >>> "Paul E. Jones" writes: >>>=20 >>>> Tim, >>>>=20 >>>> I do not agree that it's harmful. If I removed the WF discussion = off the >>>> table, I'm still having a hard time buying into everything you said = in the >>>> blog post. >>>>=20 >>>> I implement various web services, largely for my own use. Usually, = I >>>> implement all of them in XML, JSON, plain text (attribute/value = pairs), AND >>>> JavaScript (for JSONP). For simple services, it's not hard. I do = it >>>> because I sometimes have different wants/desires on the client = side. (For >>>> more complex ones, I use XML.) >>>=20 >>> As an individual (and not the chair of OAUTH) I believe that the = server >>> should be allowed, no encouraged, to support multiple formats for = data >>> retrieval. I also believe that clients should be allowed to choose = only >>> one. I am fine with JSON being Mandatory to Implement. I am NOT = okay >>> with making it the only one, and I am even less okay with mandating = it >>> is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- = you >>> can convince me either way) XML, and MAY for anything else that = people >>> feel stronly about (although I feel in 2012 XML and JSON are the two >>> best). I also feel it is okay to say that a client MUST implement = one >>> of JSON or XML, and MAY implement more. >>>=20 >>> >>>=20 >>> Note that this is a replay of the historical "MUST Implement" versus >>> "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON = and >>> XML does not mean that a Client must use both (or even that a client >>> must implement both). It is perfectly reasonable and generally >>> acceptable to have a server that provides data in multiple formats >>> whereas the client only supports a subset and specifies which = format(s) >>> are acceptable. >>>=20 >>> >>>=20 >>=20 >> This is the most sensible path forward. A MUST for JSON and XML (I'm = going with a MUST for XML to maintain backwards compatibility with RFC = 6415) on the server side and a client can choose whatever format it = wants. This is the approach taken in the current WebFinger draft. If we = reach consensus that we must mandate a client format (Note: I don't = personally think we need to), then so be it. >>=20 >> Cheers, >>=20 >> Gonzalo >>=20 >>> -derek >>>=20 >>> --=20 >>> Derek Atkins 617-623-3745 >>> derek@ihtfp.com www.ihtfp.com >>> Computer and Internet Security Consultant >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From ve7jtb@ve7jtb.com Fri Apr 20 11:52:38 2012 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 687B221F865B for ; Fri, 20 Apr 2012 11:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZEEvu4l6tCA for ; Fri, 20 Apr 2012 11:52:38 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1439B21F8624 for ; Fri, 20 Apr 2012 11:52:36 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so6754188wgb.13 for ; Fri, 20 Apr 2012 11:52:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=KE5ct838KBuxm1osYo75cK3R/TPIR0gUnJVv4uR5Mx0=; b=CFeFG/ebwdjmWPUWtElX6NCI+uKCwtvTGCabhsucA9A3cgPvkLQXsbC+V+y2hmtkrI Gunlu42I9IN7m8x6Viim3UZpx4t3MwWNSTxWQAjvGPGfQC5uk9QG+nZo5s3gcRgT9S2Q zK5i2AgYkUfK5RoYg6QiaU0TygGtyGOJyaF1Lnz1pKNyr9Y2PkD14l0VaGym8oIBvoaP G+5jMfT1BUkEoO+VohXClPviIHFR6s30ZSKE4Fafp5Lshlr3+wbMSque4IJlqE1m6W+y Fu14JfP6BT3sBNq8DhvGqyaTpWutR0aTdYKFYfnc616LIVRBnd5d7/ty5npKU8pbkaiW o1iA== Received: by 10.216.225.12 with SMTP id y12mr4369328wep.39.1334947956140; Fri, 20 Apr 2012 11:52:36 -0700 (PDT) Received: from [10.38.132.184] (ip-109-43-0-56.web.vodafone.de. [109.43.0.56]) by mx.google.com with ESMTPS id k6sm7414380wie.9.2012.04.20.11.52.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Apr 2012 11:52:25 -0700 (PDT) References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> <7F48DDA5-EA3C-45B0-90E0-C39F06748B35@cisco.com> <1BE3A02A-7287-4401-8B73-366390CB3676@ve7jtb.com> <379ABFA6-E78C-4CD4-B7F7-6E0EC452DF74@cisco.com> In-Reply-To: <379ABFA6-E78C-4CD4-B7F7-6E0EC452DF74@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-09FADAEF-74AD-431C-AF9F-A7EBE6E17A86; protocol="application/pkcs7-signature" Message-Id: X-Mailer: iPhone Mail (9B179) From: John Bradley Date: Fri, 20 Apr 2012 20:52:36 +0200 To: Gonzalo Salgueiro X-Gm-Message-State: ALoCoQnxhrlwejQpjcojHaH9sdSWl6HEzo9bJ6K9ARZ6tjLzMI5VIgbjOLzuFPcNp02Fxd5/gsvW Cc: Derek Atkins , "oauth@ietf.org" , Apps Discuss Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 18:52:38 -0000 --Apple-Mail-09FADAEF-74AD-431C-AF9F-A7EBE6E17A86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 6415 supporting a XML format doesn't require everything that uses it to supp= ort XML.=20 John B =20 Sent from my iPhone On 2012-04-20, at 7:34 PM, Gonzalo Salgueiro wrote: > 6415 --Apple-Mail-09FADAEF-74AD-431C-AF9F-A7EBE6E17A86 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MjAxODUyNDBaMCMGCSqGSIb3DQEJBDEWBBS3PW+P 7TCX0GSF5TS7QqEJp/2mRTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQCG0W7eCX++qaO3iEFiRXbqjwSwq2mHo4dhBz/0 ljD8u1QyobZN0xvlH/VJE5S8CeH1yfLC5yrVCn5kJqaLyPIheTqbri47ip7ofQP0lhCuzod2pqAQ jfEtTeNjH8Y5S9wbRAnizShFum3ee2Mqw1h532BUL+pzBLjBK6RC0pzhnh+MMJ4WXL651r7epT3c rEnl5rnH+n6bhnx6cFbORQpjXYNAYPSeoCxqGi5ITMdbAV1UgxEoGFd+XOmtQ5rxUJIAQcFSBXKz FyP5Z0PYT1VhdbrgTV8odIaa3+GEyJg237wVcAEdqhpPJCGKe7Lr8WiTUa+/iArYtI7IkzWWC9gc AAAAAAAA --Apple-Mail-09FADAEF-74AD-431C-AF9F-A7EBE6E17A86-- From gffletch@aol.com Fri Apr 20 12:59:02 2012 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 25E6621F8638; Fri, 20 Apr 2012 12:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-bRWOA5rpJk; Fri, 20 Apr 2012 12:59:01 -0700 (PDT) Received: from imr-da02.mx.aol.com (imr-da02.mx.aol.com [205.188.105.144]) by ietfa.amsl.com (Postfix) with ESMTP id 1B64F21F8637; Fri, 20 Apr 2012 12:58:59 -0700 (PDT) Received: from mtaout-mb02.r1000.mx.aol.com (mtaout-mb02.r1000.mx.aol.com [172.29.41.66]) by imr-da02.mx.aol.com (8.14.1/8.14.1) with ESMTP id q3KJwQ1A003342; Fri, 20 Apr 2012 15:58:26 -0400 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 3305CE000141; Fri, 20 Apr 2012 15:58:26 -0400 (EDT) Message-ID: <4F91BFE1.8070803@aol.com> Date: Fri, 20 Apr 2012 15:58:25 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Christian Weiske References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com> <9B6B7851-5212-4313-88B5-DBBA7BC9BEDC@gmail.com> <20120419181533.39c1de8e@bogo> In-Reply-To: <20120419181533.39c1de8e@bogo> Content-Type: multipart/alternative; boundary="------------000302080300090306060402" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1334951906; bh=IU46Pe+rEuVc4QWbmQzjfnPugyqkfojtfoJeCvVJmik=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=PI39DqLwkNVRrBYp0vaLS5X7vYTPqqvi1bgjHsDmlnPIUPoUtgje3BSc0WvljeQBS auyXemj8V8vl3xbVcSKKMqvV7yrOjbc+x6qJDQ0nKw6BVcmQO0VyY/nah/59yMZjCW HlQJTSDMM1gaMqvkNUUjQ7T1nLsB6IzrQN4jYPsY= X-AOL-SCOLL-SCORE: 0:2:448337120:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29424f91bfe27e8c X-AOL-IP: 10.181.186.254 Cc: "oauth@ietf.org WG" , apps-discuss@ietf.org Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) 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: Fri, 20 Apr 2012 19:59:02 -0000 This is a multi-part message in MIME format. --------------000302080300090306060402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit And the AOL is working as well (though it was down for a bit:) On 4/19/12 12:15 PM, Christian Weiske wrote: > Hello Dick, > > >>> Gmail, aol, and yahoo all put up webfinger endpoints, but there >>> hasn't been much movement, I think due to the chicken and egg >>> nature of adoption around decentralized tools. >> A couple months ago I was checking out what was up. The AOL and Yahoo >> endpoints no longer worked. The Google one still did. > Yahoo actually still serves the main entry point at > http://www.yahoo.com/.well-known/host-meta > that gives out the OpenID all accounts can use. > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------000302080300090306060402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit And the AOL is working as well (though it was down for a bit:)

On 4/19/12 12:15 PM, Christian Weiske wrote: 
Hello Dick,



Gmail, aol, and yahoo all put up webfinger endpoints, but there
hasn't been much movement, I think due to the chicken and egg
nature of adoption around decentralized tools.


      

        
A couple months ago I was checking out what was up. The AOL and Yahoo
endpoints no longer worked. The Google one still did.


      

      
Yahoo actually still serves the main entry point at
http://www.yahoo.com/.well-known/host-meta
that gives out the OpenID all accounts can use.



      

      

      

      
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


    

    

  


--------------000302080300090306060402--

From stephen.farrell@cs.tcd.ie  Fri Apr 20 19:41:54 2012
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 BE2A311E8096; Fri, 20 Apr 2012 19:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK4wUbdfv091; Fri, 20 Apr 2012 19:41:50 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 22B1411E808A; Fri, 20 Apr 2012 19:41:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C810A17147D; Sat, 21 Apr 2012 03:41:48 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334976104; bh=ICPLx86NWbFknU Qx2u4DGPOjo20qKC3hpjyw39tCNSI=; b=yfUVSBGkmwsfCPuXiPkleb5EJ4QBKs ytMa1hQaQhyrMzT1kIEhzHVBFtqf+leB87TdGDRn+35kgj/LUaiNQvH84A6U4pwm XPWWNWdrCVbSw2Pgy7hBhGkLWc68fyLWg0qLuSgRhv291Z/1SNiah5VWGAw8aDr5 vQu6H+l+DXHKEWl9cQi+QS0aqa2W73TxzJ2XEOgxgxZ2WiylbiyEcs1Mmueu22ji Q52qyjTWmAtFyTLMsDV2r2OBuPcpUmMcwedfwoCSdfN76TUtU3gqAghHkPXtJpR2 Xu/4TOEnvh9NbYSgTclETo48fpvZL8I8wLVL3WCATgvpfrXYxXJZmMkA==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id p6k32XsAcmT6; Sat, 21 Apr 2012 03:41:44 +0100 (IST)
Received: from [1.202.85.154] (unknown [1.202.85.154]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BF055171474; Sat, 21 Apr 2012 03:41:34 +0100 (IST)
Message-ID: <4F921E53.8030109@cs.tcd.ie>
Date: Sat, 21 Apr 2012 03:41:23 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Michael Thomas 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>
In-Reply-To: <4F917545.5080103@mtcc.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Derek Atkins , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Sat, 21 Apr 2012 02:41:54 -0000

On 04/20/2012 03:40 PM, Michael Thomas wrote:
> 
> Why not MUST ASN.1 while you're at it? JSON has won in case
> you'all haven't noticed it.

Well, I also remember when XML won over ASN.1, or
was that some RPC thing? Seems like a new format wins
about every five years or so, once the last winner
gets enough crap added. (JSON pointer seems like the
start of a nice slippery slope to me.)

I've no opinion as to what should be MTI here however,
just a side comment.

S

> 
> Mike
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 

From paulej@packetizer.com  Fri Apr 20 20:33:51 2012
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 16EB111E8099; Fri, 20 Apr 2012 20:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.379
X-Spam-Level: 
X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJhs2Rhy3thz; Fri, 20 Apr 2012 20:33:46 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id ACFA011E809B; Fri, 20 Apr 2012 20:33:46 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3L3Xjwa006602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 23:33:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334979226; bh=7asx+dAcTcnbVW7JJuWAQg3hlJHRj0hk3THAnh4+8Dc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=pYN08uIQwe6j6ib8tUxCW2AwNvti5R95WfssdLPXGQQF1lu6U7W3lNwJXrtakck4j 1SqncHDRytxxpAlM+W5nCAP2Zv9KKctY8nrbFXlofBWl5q4ulNU2+HbnSFezsf1X+R tJSBjD/Y6Q/TAk/Szw5gS6f5IHjEyMuLnnhRr4w4=
From: "Paul E. Jones" 
To: "'Derek Atkins'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net>	<4F8852D0.4020404@cs.tcd.ie>	<9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>		<9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com>	<4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>	<091401cd1ea3$e159be70$a40d3b50$@packetizer.com>		<091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com> 
In-Reply-To: 
Date: Fri, 20 Apr 2012 23:34:08 -0400
Message-ID: <0a7401cd1f6f$9cb98fd0$d62caf70$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCO5nRqZW2qKXg
Content-Language: en-us
Cc: 'Tim Bray' , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Sat, 21 Apr 2012 03:33:51 -0000

Derek,

> > I do not agree that it's harmful. If I removed the WF discussion off
> > the table, I'm still having a hard time buying into everything you
> > said in the blog post.
> >
> > I implement various web services, largely for my own use.  Usually, I
> > implement all of them in XML, JSON, plain text (attribute/value
> > pairs), AND JavaScript (for JSONP).  For simple services, it's not
> > hard.  I do it because I sometimes have different wants/desires on the
> > client side.  (For more complex ones, I use XML.)
> 
> As an individual (and not the chair of OAUTH) I believe that the server
> should be allowed, no encouraged, to support multiple formats for data
> retrieval.  I also believe that clients should be allowed to choose only
> one.  I am fine with JSON being Mandatory to Implement.  I am NOT okay
> with making it the only one, and I am even less okay with mandating it is
> the ONLY one.  I would say MUST JSON, MUST (or possibly SHOULD -- you can
> convince me either way) XML, and MAY for anything else that people feel
> stronly about (although I feel in 2012 XML and JSON are the two best).  I
> also feel it is okay to say that a client MUST implement one of JSON or
> XML, and MAY implement more.

I hope I didn't mislead you with my statements.  I definitely was not
suggesting we have more than XML and JSON on the server.  I was merely
pointing out that I've found it fairly simple on the server side to offer
multiple formats.  Spewing data out in some format is trivial, usually.

My preference has been MUST for XML and JSON since 1) XML is already a MUST
in RFC 6415 and we'd have to "break" what is there now to remove the MUST
and 2) people are clearly demanding JSON.
 
> 
> 
> Note that this is a replay of the historical "MUST Implement" versus "MUST
> Use" arguments.  Just because the server MUST IMPLEMENT JSON and XML does
> not mean that a Client must use both (or even that a client must implement
> both).  It is perfectly reasonable and generally acceptable to have a
> server that provides data in multiple formats whereas the client only
> supports a subset and specifies which format(s) are acceptable.
> 
> 

Definitely... clients would only have to implement what they prefer.  Only
the server would be required to implement both.  (Still, there is contention
over requiring both on the server.)

Paul



From paulej@packetizer.com  Fri Apr 20 21:10:58 2012
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 7BE3521F84CE; Fri, 20 Apr 2012 21:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.385
X-Spam-Level: 
X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li4SsUxLjB7T; Fri, 20 Apr 2012 21:10:54 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 20C3311E8096; Fri, 20 Apr 2012 21:10:54 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3L4AqlP007576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Apr 2012 00:10:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334981453; bh=KDwCeSgGzRvPy3FXQQ+8ar2XSBUKPT0PE4xFuUK9mfg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Q6+xsuLGqdBvPVyzWK+AW9FjgxJrSAwCjqf3nbZLHJDfz53FYCw6iES0LdmHjzOsq xU3nMsKQe1+Yl/r2mDyrCygnBKX8WY3t65Zfwbl+VYzr1CMWPHOX1W3JzufWx037lv Lin3BmgNqUseSdP9M/7LuTtndGdenzKM/EKosevs=
From: "Paul E. Jones" 
To: "'Michael Thomas'" , "'Derek Atkins'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917CE6.2060904@mtcc.com>
In-Reply-To: <4F917CE6.2060904@mtcc.com>
Date: Sat, 21 Apr 2012 00:11:15 -0400
Message-ID: <0a7601cd1f74$cc5a26a0$650e73e0$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCO5nRqQE1p72claz9LfA=
Content-Language: en-us
Cc: 'Tim Bray' , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Sat, 21 Apr 2012 04:10:58 -0000

Mike,

> On 04/20/2012 07:17 AM, Derek Atkins wrote:
> >  Note that this is a replay of the historical "MUST
> > Implement" versus "MUST Use" arguments. Just because the server MUST
> > IMPLEMENT JSON and XML does not mean that a Client must use both (or
> > even that a client must implement both). It is perfectly reasonable
> > and generally acceptable to have a server that provides data in
> > multiple formats whereas the client only supports a subset and
> > specifies which format(s) are acceptable.  -derek
> 
> To Paul's point about how easy it is for a server to support both, I'd
> retort that it's equally easy for a client to gin up JSON instead of XML.

I don't follow.

I agree I could write a client that could do JSON easily.
I agree I could write a client that could do XML easily.

What is a pain on the client side is conditional code that has to be
followed in order to consume whatever the server wants to send.  The client
should have a single code path knowing it will get what it wants, ether XML
or JSON.

Granted, the server has to have a conditional statement and generate XML or
JSON as requested.  However, generating either is trivial.  Really, I did it
in minutes.  We're not talking about huge complex data structures here with
WebFinger.

> Pity the poor programmer who can't get their head around that gigantic
> change. On the other hand, having to support XML and JSON is an ongoing
> maintenance headache server-side. Why do it?

Would we expect to see a lot of changes to the data structures used by
WebFinger?  That's really the only ongoing maintenance issue.  Don't touch
the code that produces the XML or JSON and there is no ongoing maintenance.

> There isn't even the dubious
> religious war like back in the day saying that binary encoded ASN.1 was
> "better/faster/stacks and cleans dishes" than "human readable" XML.  XML
> is just a clunky and past its prime text encoding at this point. Requiring
> it smacks of nostalgia to me.

I disagree with you on that one.  First, ASN.1 is better for defining
protocols, so long as you stay away from the complex stuff. Basic ASN.1
looks a lot like C and produces C data structures that can be readily read,
decoded, and consumed in C code.  Rarely, rarely do I see decoding issues
when using ASN.1, whereas issues pop up quite often with text protocols,
especially things like SIP where a semi-colon in the wrong place breaks
things.  But, let's not start that debate again ;-)

XML *can* be big and clunky.  As you've well noticed, I can also write
lengthy emails that seem to have more typos as the evening progresses. :-)

However, XML can be a very compact encoding and it's extremely readable.

I just did a query on my server to see the XML vs. JSON output.  The XRD
document provided was 1032 octets.  The JRD document was 1077 octets.
Removing every possible space and making both formats hard as heck to read,
JSON was 837 and XML was 940.  I'm hard pressed to say that's makes much
difference.  Further, I can't read either of them now without some effort.

Considering that a lot of WebFinger use (I suspect) is going to be
server-to-server interaction, XML seems like a reasonable format to retain.
That, and the fact it is already mandatory in RFC 6415 and deployed out
there.

It's not nostalgia for me.  XML is a very well-structured, readable format.
No objection to JSON, but I really don't understand the clamoring for JSON.
I guess more precisely, I don't understand the disdain for XML.  Is it
because people created hideously complex XML data structures and feel pain
for having done that?  XRD is not that kind of document.

Paul



From paulej@packetizer.com  Fri Apr 20 21:24:31 2012
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 A3FCD11E809D; Fri, 20 Apr 2012 21:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.391
X-Spam-Level: 
X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-iEXiE6iwzY; Fri, 20 Apr 2012 21:24:27 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1047211E8091; Fri, 20 Apr 2012 21:24:26 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3L4O1FV007965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Apr 2012 00:24:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334982243; bh=rq9Qhie9YBoqXCMq5TqCDLkTzRbzBmcowU6iWcZz2EE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=RjKH79HhelwJ1XwkspthT9PjI5y8qLjApQlJK3U49oS2KtIDTge727dwIbHA1k2P6 qpyMk8v0vquUvUaj+7Izz0QnzFf8tEmK7rVu61bRxK7B92260H5jR8UFlOudl3ffpr 9F5g+8Yp97cIijieEC0/QJpZsWeSk1esxeVpiBZc=
From: "Paul E. Jones" 
To: "'Daniel Renfer'" , "'William Mills'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com> 
In-Reply-To: 
Date: Sat, 21 Apr 2012 00:24:25 -0400
Message-ID: <0a7801cd1f76$a33d7bd0$e9b87370$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAI8MBwxAc/xlwgBkQ/oMAJ4RBC2AnnCY7eVj8CiwA==
Content-Language: en-us
Cc: oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Sat, 21 Apr 2012 04:24:31 -0000

Daniel,

If the resource parameter is required, what would break are new clients =
that rely on it.  Thus, we have a forward-compatibility issue.  That is =
an issue, which is why we made it optional.  (But I've said that.)

I think a question is whether we can accept this "new client" issue as =
an interim situation while servers are upgraded to support the resource =
parameter.  If people feel the answer is "no" then we need to keep it =
optional.  If "yes", we could make it mandatory.

We also have those who want to be able to run WebFinger on static sites. =
 It's hard to ignore that if there are really those who want to do it.

On the SWD side, there is clearly a desire to be able to make a single =
query and get a single response.  I can appreciate that, since otherwise =
one would have to perform two queries and construct the JRD on the =
client side (or at least go sifting through replies looking for the =
proper link relations and values).

Paul

> -----Original Message-----
> From: Daniel Renfer [mailto:duck@kronkltd.net]
> Sent: Friday, April 20, 2012 11:09 AM
> To: William Mills
> Cc: Mike Jones; Paul E. Jones; Murray S. Kucherawy; oauth@ietf.org; =
Apps
> Discuss
> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web =
Discovery
> (SWD)
>=20
> The point is that existing WF clients have been written to not use the
> resource parameter because in the past, that parameter hasn't been
> available or hasn't been reliable.
>=20
> If the resource parameter is required, this older method of fetching =
the
> host meta and constructing the url to fetch the user meta would still
> continue to work just as before.
>=20
> Even if the resource parameter were made mandatory today, real world =
WF
> clients would still have to account for the possibility of resource
> queries resulting in an error or incorrect information. Given the =
number
> of currently deployed WF-enabled services and the difficulty in =
upgrading
> all of them, this is going to be the case for some time.
>=20
> resource parameters should be strongly encouraged, but not required.
>=20
> On Fri, Apr 20, 2012 at 10:45 AM, William Mills 
> wrote:
> > So you are guaranteeing that there are no clients using WF today?
> >
> > ________________________________
> > From: Mike Jones 
> > To: Paul E. Jones ; 'Murray S. Kucherawy'
> > ; "oauth@ietf.org" ; 'Apps =
Discuss'
> > 
> > Sent: Thursday, April 19, 2012 10:48 PM
> > Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web
> > Discovery
> > (SWD)
> >
> > To be clear, making this mandatory would break no clients.  It would
> > require updating some servers, just as requiring JSON would.  This
> > seems like a fair tradeoff when it makes an appreciable difference =
in
> > user interface latency in some important scenarios.  If you and the
> > other key WebFinger supporters can agree to making "resource" =
support
> > mandatory and requiring JSON, I believe we may have a path forward.
> >
> >                 Cheers,
> >                 -- Mike
> >
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej@packetizer.com]
> > Sent: Thursday, April 19, 2012 10:39 PM
> > To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps =
Discuss'
> > Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> > Discovery
> > (SWD)
> >
> > That's correct.  We could certainly make it mandatory, but the =
reason
> > it isn't is to maintain backward compatibility with existing
> deployments.
> >
> > I think we should always think carefully when we decide to make a
> > change that breaks backward-compatibility.  This is one change that
> would do that.
> >
> > Paul
> >
> >> -----Original Message-----
> >> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> >> Sent: Friday, April 20, 2012 1:10 AM
> >> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps
> Discuss'
> >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> >> Discovery
> >> (SWD)
> >>
> >> Currently, support for the "resource" parameter is optional, as per
> >> the following (correct?):
> >>
> >>    Note that support for the "resource" parameter is optional, but
> >>    strongly RECOMMENDED for improved performance.  If a server does
> >>not
> >>    implement the "resource" parameter, then the server's host
> >>metadata
> >>    processing logic remains unchanged from RFC 6415.
> >>
> >> To truly support 1, this would need to be changed to REQUIRED, =
correct?
> >>
> >>                 -- Mike
> >>
> >> -----Original Message-----
> >> From: Paul E. Jones [mailto:paulej@packetizer.com]
> >> Sent: Thursday, April 19, 2012 8:16 PM
> >> To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps =
Discuss'
> >> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
> >> Discovery
> >> (SWD)
> >>
> >> Mike,
> >>
> >> > There are two criteria that I would consider to be essential
> >> > requirements for any resulting general-purpose discovery
> specification:
> >> >
> >> > 1.  Being able to always discover per-user information with a
> >> > single GET (minimizing user interface latency for mobile devices,
> >> > etc.)
> >>
> >> WF can do that.  See:
> >> $ curl -v https://packetizer.com/.well-known/\
> >>          host-meta.json?resource=3Dacct:paulej@packetizer.com
> >>
> >> > 2.  JSON should be required and it should be the only format
> >> > required (simplicity and ease of deployment/adoption)
> >>
> >> See the above example.  However, I also support XML with my server.
> >> It took me less than 10 minutes to code up both XML and JSON
> >> representations.
> >> Once the requested format is determined, the requested URI is
> >> determined, data is pulled from the database, spitting out the
> >> desired format is trivial.
> >>
> >> Note, and very important note: supporting both XML and JSON would
> >> only be a server-side requirement.  The client is at liberty to use
> >> the format it prefers.  I would agree that forcing a client to
> >> support both would be unacceptable, but the server?  Nothing to it.
> >>
> >> > SWD already meets those requirements.  If the resulting spec =
meets
> >> > those requirements, it doesn't matter a lot whether we call it
> >> > WebFinger or Simple Web Discovery, but I believe that the
> >> > requirements discussion is probably the most productive one to be
> >> > having at this point - not the starting point document.
> >>
> >> I believe WebFinger meets those requirements.  We could debate
> >> whether XML should be supported, but I'll note (again) that it is
> >> there in RFC 6415.
> >> That document isn't all that old and, frankly, it concerns me that =
we
> >> would have a strong preference for format A one week and then =
Format
> >> B the next.
> >> We are where we are and I can see reason for asking for JSON, but =
no
> >> good reason to say we should not allow XML (on the server side).
> >>
> >> Paul
> >>
> >>
> >>
> >
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >


From paulej@packetizer.com  Fri Apr 20 21:39:13 2012
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 3C53611E80A4; Fri, 20 Apr 2012 21:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55A+f-g4vcIQ; Fri, 20 Apr 2012 21:39:09 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 428F611E8096; Fri, 20 Apr 2012 21:39:08 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3L4d7D3008366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Apr 2012 00:39:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1334983147; bh=kQyg8yLylLIR5T9g2XktRYKeYgnSFcyhiz5GHdF5ZIU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jInKwDCk6HeAl+5r8E3VsRdo3jsEo7js62KkEn9avKQXr/AHalN4fz18fi/rYFBbW OfAZMT/K8s8AFWRvTnRJK1QIstjTCseRIdTZsur0JGaq5q1o573BhIFV+TU3GAnkgZ TPy72IMC9wb7c3C4kFDDJXKLTO9TP2NP5ekbvIiI=
From: "Paul E. Jones" 
To: "'Michael Thomas'" , "'Derek Atkins'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>
In-Reply-To: <4F917545.5080103@mtcc.com>
Date: Sat, 21 Apr 2012 00:39:30 -0400
Message-ID: <0a7a01cd1f78$be37b1b0$3aa71510$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCO5nRqQLuh1nulZ9D7dA=
Content-Language: en-us
Cc: 'Tim Bray' , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Sat, 21 Apr 2012 04:39:13 -0000

Michael,

> > am NOT okay with making it the only one, and I am even less okay with
> > mandating it is the ONLY one.  I would say MUST JSON, MUST (or
> > possibly SHOULD -- you can convince me either way) XML, and MAY for
> > anything else that people feel stronly about (although I feel in 2012
> > XML and JSON are the two best).  I also feel it is okay to say that a
> > client MUST implement one of JSON or XML, and MAY implement more.
> >
> >
> 
> Why not MUST ASN.1 while you're at it? JSON has won in case you'all
> haven't noticed it.

"Won"? Data formats are not popularity contests.  This is the Internet
Engineering Task Force, not the Internet Entertainment Task Force.  (That
said, a few recent message have been entertaining.)  We should be building
and designing systems for longevity.  XML was absolutely *the* thing just a
few years ago and now JSON is all the rage.  How long will that last before
"the next great thing" comes along?

There are many people who value XML still, in spite a growth in the use of
JSON.

Paul



From tbray@textuality.com  Sat Apr 21 12:27:03 2012
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 A003121F8598 for ; Sat, 21 Apr 2012 12:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.066
X-Spam-Level: 
X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqz6RffIotdk for ; Sat, 21 Apr 2012 12:26:59 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A246A21F857D for ; Sat, 21 Apr 2012 12:26:59 -0700 (PDT)
Received: by obbwd20 with SMTP id wd20so11003037obb.31 for ; Sat, 21 Apr 2012 12:26:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=kfvVYONDB88l0xkjDZL0SwT+s0VmIqgPhG3ydNneKD8=; b=Y7api0viv5F1mvXTutwIINM2+KME7UXzKOpaZnz5WONxnnIX1OnuN+wJMfmb7QzXug ULyjNpAU/kJE/xi8L7D/LninaOtgadpDKG7NsIkCAAb4TFjj52vJvMu/EW7/Q9rvZcJb p8WHw16JBDFwqL4mla/zWI+3SK2VbW+28juV1+lzDZ4X1cKxEyas2vQHri/vaUL/ye8N u42y2O5aEz+cLn5J+qPxCDMZ26I/ujLlad7z487diePr5Q8qeWisfUHyd9q2SN9ZWctH dDZJkFwYxyZPd5Kup/JL6gwyFHNdlAHqfgiC+n9okRNgnJY3wFBjS1jUrwARksbyO4BC jfAA==
MIME-Version: 1.0
Received: by 10.60.7.103 with SMTP id i7mr9346188oea.64.1335036419066; Sat, 21 Apr 2012 12:26:59 -0700 (PDT)
Received: by 10.182.204.71 with HTTP; Sat, 21 Apr 2012 12:26:59 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com> <4F921E53.8030109@cs.tcd.ie> 
Date: Sat, 21 Apr 2012 12:26:59 -0700
Message-ID: 
From: Tim Bray 
To: Bob Wyman 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmp/AjaHgL3NpPq613tgMT8Lft6LUXnCeR3BTWkmY7kv+uhN2ClzmlhJMhXhyQ/NW7apgLQ
Cc: Derek Atkins , oauth@ietf.org, Apps Discuss 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Sat, 21 Apr 2012 19:27:03 -0000

That might have happened had there been some free high-quality ASN.1
software, instead of slow buggy parsers that cost $50K to license.
It=92s always seemed to me that one reason XML took off so fast is that
there were fast robust open-source parsers in C and Java before the
spec was even finalized.

But we digress... -T

On Sat, Apr 21, 2012 at 10:14 AM, Bob Wyman  wrote:
>
>
> On Fri, Apr 20, 2012 at 10:41 PM, Stephen Farrell
>  wrote:
>>
>>
>>
>> On 04/20/2012 03:40 PM, Michael Thomas wrote:
>> >
>> > Why not MUST ASN.1 while you're at it? JSON has won in case
>> > you'all haven't noticed it.
>>
>> Well, I also remember when XML won over ASN.1, or
>> was that some RPC thing?
>
> Of course, long before "XML won over ASN.1" ASN.1 won over XML's
> predecessor; SGML. Back in the early to mid-80's, when we were defining t=
he
> ISO X.4xx and X.5xx standards, the IBM and Unix crowds were pushing SGML =
as
> the alternative to the binary encodings of ASN.1. But, Digital and the
> Telcos pushed for the binary encodings and won.
>
> These days, XML is just another encoding for ASN.1 since ASN.1 finally
> defined the XML Encoding Rules (XER) a few years back.
>
> If we had agreed on ASN.1 years ago, we wouldn't be having these encoding
> format debates every few years. ASN.1 is an "Abstract Syntax Notation" th=
at
> can be mapped to a large number of encoding rules. If we were using ASN.1=
,
> what we would do is define the "schema" or syntax for data abstractly and
> then specify the actual encoding as a secondary issue. Given that one
> encoding can be translated to another, implementations would be free to u=
se
> whatever encoding was most convenient or appropriate for them. But, that
> would be a different universe than the one we live in today.
>
>> Seems like a new format wins
>> about every five years or so, once the last winner
>> gets enough crap added. (JSON pointer seems like the
>> start of a nice slippery slope to me.)
>>
>> I've no opinion as to what should be MTI here however,
>> just a side comment.
>>
>> S
>>
>> >
>> > Mike
>> > _______________________________________________
>> > apps-discuss mailing list
>> > apps-discuss@ietf.org
>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>> >
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From sm@resistor.net  Sat Apr 21 13:34:38 2012
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 747CD21F8637; Sat, 21 Apr 2012 13:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level: 
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f29x6-OKa4Mg; Sat, 21 Apr 2012 13:34:28 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3223121F862F; Sat, 21 Apr 2012 13:34:27 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3LKYGc2026824; Sat, 21 Apr 2012 13:34:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335040463; i=@resistor.net; bh=+5mMhJfFQ4BWMJ8Icp7GVOhBWz4UVJKF4S7+0wYxD8Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vvt5S4ZRrf0bohm8q5ruujMEwBMQ6mR0WdLLI+2lOdNWX2ZQ2FYrF/xA5sdFh2SqT fpnXMrC1PpbC4dAXWB6SwQ3PkQe16TFA3dGCT1PsAcukG8Wordeb5Ywn+iwZ0DirZT CQV+dPuohDzh/1U2cHwSzPk2AJHUawUqwbVFKxoA=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335040463; i=@resistor.net; bh=+5mMhJfFQ4BWMJ8Icp7GVOhBWz4UVJKF4S7+0wYxD8Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=43RCJtdrZNlO09ztdwQw5OcXR+UC1Ft+TzI0H87KkVJkZxcOq1DQUxGzswycNPqFc nktl7jHmJZPRq0dsTpo6MnheE6iU9BzYSsFE6Wl35h2YIjjGucEW0ZqLnYQwpek3Eu J/TTAEWX8so9Jd37CzUeYtmFljPEMiwo37xlxUVQ=
Message-Id: <6.2.5.6.2.20120421124344.0bc4b0c0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 21 Apr 2012 13:03:53 -0700
To: "Paul E. Jones" 
From: SM 
In-Reply-To: <0a7401cd1f6f$9cb98fd0$d62caf70$@packetizer.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <0a7401cd1f6f$9cb98fd0$d62caf70$@packetizer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: oauth@ietf.org, apps-discuss@ietf.org
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Sat, 21 Apr 2012 20:34:38 -0000

Hi Paul,
At 20:34 20-04-2012, Paul E. Jones wrote:
>My preference has been MUST for XML and JSON since 1) XML is already a MUST
>in RFC 6415 and we'd have to "break" what is there now to remove the MUST
>and 2) people are clearly demanding JSON.

MUST for XML and JSON offers choice but it does make a 
choice.  Encouraging such a polygamous relationship can only end up 
badly.  RFC 6415 was published in October 2011.  Switching 
preferences in less than a year raises some issues about the nature 
of relationships.

Anyway, whether someone break something is not as important as 
picking one option.

Regards,
-sm



From paulej@packetizer.com  Sat Apr 21 20:45:20 2012
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 BFD4821F84CF; Sat, 21 Apr 2012 20:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.727
X-Spam-Level: 
X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doymfko5hrGX; Sat, 21 Apr 2012 20:45:19 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B1B3C21F84C8; Sat, 21 Apr 2012 20:45:19 -0700 (PDT)
Received: from dyn-129.arid.us (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3M3jGDt011397 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 21 Apr 2012 23:45:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335066319; bh=sSlvyVlRZHBxrKkue4EWtHU7V1nlt1K+Sm4tjIy+ecA=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=X5CHxNlxpV3V4oaZbJNjCkQYZbsISYdhmYG5WxJF9G5YfJOjBlE+Pggz63oGdJ3qJ sgaUa4m6HNFU9FSaF4FzfKWsr/1cjyqnMq4o3Usi7Z6ysoa0VrQraThzahV3YcqEDj 8spzivZawFnUFCxoC2hTPsnXzeBdrCYYOZbIjUTU=
User-Agent: Kaiten Mail
In-Reply-To: <6.2.5.6.2.20120421124344.0bc4b0c0@resistor.net>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <0a7401cd1f6f$9cb98fd0$d62caf70$@packetizer.com> <6.2.5.6.2.20120421124344.0bc4b0c0@resistor.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----9E36R68R5PZ2DIB67SRN7WKUNISUQN"
From: "Paul E. Jones" 
Date: Sat, 21 Apr 2012 23:45:14 -0400
To: SM 
Message-ID: <53ebd614-da85-4a82-a4cf-85454577c6ec@email.android.com>
Cc: oauth@ietf.org, apps-discuss@ietf.org
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Sun, 22 Apr 2012 03:45:20 -0000

------9E36R68R5PZ2DIB67SRN7WKUNISUQN
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

Note that requiring both would only be on the server side. While JSON might be the new hip format, I suspect some will use XML for some time. And there are some link relations that might point to XML content. For certain applications like OpenID Connect, they could get by with JSON only, but I bet many other applications will have to deal with a variety of content types, like hcard, vcard, portable contacts, and others that might use something else.

Paul


-------- Original Message --------
From: SM 
Sent: Sat Apr 21 16:03:53 EDT 2012
To: "Paul E. Jones" 
Cc: oauth@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web  Discovery (SWD)

Hi Paul,
At 20:34 20-04-2012, Paul E. Jones wrote:
>My preference has been MUST for XML and JSON since 1) XML is already a MUST
>in RFC 6415 and we'd have to "break" what is there now to remove the MUST
>and 2) people are clearly demanding JSON.

MUST for XML and JSON offers choice but it does make a 
choice.  Encouraging such a polygamous relationship can only end up 
badly.  RFC 6415 was published in October 2011.  Switching 
preferences in less than a year raises some issues about the nature 
of relationships.

Anyway, whether someone break something is not as important as 
picking one option.

Regards,
-sm



------9E36R68R5PZ2DIB67SRN7WKUNISUQN
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

Note that requiring both would only be on the server side. While JSON might be the new hip format, I suspect some will use XML for some time. And there are some link relations that might point to XML content. For certain applications like OpenID Connect, they could get by with JSON only, but I bet many other applications will have to deal with a variety of content types, like hcard, vcard, portable contacts, and others that might use something else.



Paul




From: SM <sm@resistor.net>

Sent: Sat Apr 21 16:03:53 EDT 2012

To: "Paul E. Jones" <paulej@packetizer.com>

Cc: oauth@ietf.org, apps-discuss@ietf.org

Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web  Discovery (SWD)






Hi Paul,
At 20:34 20-04-2012, Paul E. Jones wrote:
>My preference has been MUST for XML and JSON since 1) XML is already a MUST
>in RFC 6415 and we'd have to "break" what is there now to remove the MUST
>and 2) people are clearly demanding JSON.

MUST for XML and JSON offers choice but it does make a 
choice.  Encouraging such a polygamous relationship can only end up 
badly.  RFC 6415 was published in October 2011.  Switching 
preferences in less than a year raises some issues about the nature 
of relationships.

Anyway, whether someone break something is not as important as 
picking one option.

Regards,
-sm



------9E36R68R5PZ2DIB67SRN7WKUNISUQN--


From eve@xmlgrrl.com  Sun Apr 22 13:43:46 2012
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 B000821F854C for ; Sun, 22 Apr 2012 13:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.293
X-Spam-Level: 
X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306,  URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2eygMqB4A6f for ; Sun, 22 Apr 2012 13:43:45 -0700 (PDT)
Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id B3B9421F8546 for ; Sun, 22 Apr 2012 13:43:45 -0700 (PDT)
Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q3MKhh68017731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Apr 2012 13:43:44 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Eve Maler 
In-Reply-To: <4F9059F5.1050705@lodderstedt.net>
Date: Sun, 22 Apr 2012 13:43:43 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F88713C.6070309@mitre.org>  <4F8C6D43.2030701@mitre.org> <4F8F1B9F.1040302@lodderstedt.net> <4F8F1D94.4090208@mitre.org> <4F8F1F9C.7020008@lodderstedt.net> <4F8F22C4.6000900@mitre.org> <4F9059F5.1050705@lodderstedt.net>
To: Torsten Lodderstedt 
X-Mailer: Apple Mail (2.1257)
Cc: Derek Atkins , "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
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: Sun, 22 Apr 2012 20:43:46 -0000

Once again, you may want to look at the UMA core I-D to see how it =
defines an AS/RS interface:

http://tools.ietf.org/html/draft-hardjono-oauth-umacore-04
(see particularly Section 3.3)

It uses what is by now a very common token introspection pattern to have =
the RS get the AS's crucial help in validating the token that was =
presented to it. UMA has a mandatory-to-implement token profile called =
"bearer", which treats the token introspection endpoint as a run-time =
way to get the content associated with the token blob. Obviously, what's =
returned from that call is currently UMA-specific (and in fact this =
class of profiles is called "UMA token profiles"). Note that the call to =
the token introspection endpoint must be accompanied by an OAuth token =
in the header because the endpoint is OAuth-protected. (Yes, it's =
turtles all the way down...) We haven't yet defined an "UMA JWT token =
profile", but that's the next logical step.

This type of introspection functionality could be called a narrow =
definition of the AS/RS interface requirement. To make it possible to =
have the AS and RS live in completely separate domains potentially =
controlled by different parties (a broad definition), a number of other =
elements would ultimately be required. This is where UMA's entire =
"protection API" may be interesting to look at, since it has been =
demonstrated to apply to typical OAuth use cases (single resource owner) =
as well as access management use cases (resource owner and requesting =
party are different).

	Eve

On 19 Apr 2012, at 11:31 AM, Torsten Lodderstedt wrote:

> Hi Justin,
>=20
> In my opinion, the OpenID Connect introspection/checkid endpoint is a =
convenience function for clients (not resource servers) unable to =
decrypt id tokens and validate their signatures. I'm not convinced this =
function is needed, that's why I proposed to drop it.
>=20
> The AS-PR endpoint servers a different purpose, as it allows to =
implement handle-based token designs. The AS just creates simple token =
(e.g. a random number), which is very small and does not need to be =
encrypted or signed. This might result in simple designs. On the other =
hand, the PR needs to lookup authz data as part of the request =
implementation, which might have a negative impact on performance and =
scalability. That's where self-contained tokens, such as JWT have their =
merits.
>=20
> I don't think one would combine self-contained tokens with an AS-PR =
endpoint. Or is this the case in any existing implementations?
>=20
> The point I wanted to make is: no matter how the resource server =
acquires authz data (as token content/JWT or via request to another =
AS-PR endpoint), the authz data will be the same. And as part of the JWT =
standardization, we will identify this data and specify a JSON format to =
represent it. The same representation could be used at the AS-PR =
endpoint as well.
>=20
> regards,
> Torsten.
>=20
> Am 18.04.2012 22:23, schrieb Justin Richer:
>> I think we might be crossing wires about input to the token =
introspection endpoint vs. output from it.
>>=20
>> In OpenID Connect, you send a JWT in, and get back a JSON object that =
represents the Claims bit of the JWT.
>>=20
>> In our implementation (and I think both Ping and AOL's), you send in =
an arbitrary token (with no proscribed format) and get back a JSON =
object with different pieces in it. Ours included a list of scopes and =
an expiration timestamp, others did different things, like audience and =
issuer, as part of the return.
>>=20
>> The point I was trying to make is that the information returned from =
the AS-PR interface isn't necessarily embedded inside of the token used =
to call that interface. In OpenID Connect, it is, and the CheckID =
endpoint just unwraps the JWT for you. In the larger case, what's really =
going on is that the PR presents a token that it's not sure what it's =
good for and gets back something that answers that question. Since a JWT =
Claims section can be an arbitrary JSON object (for all intents and =
purposes), you could use a JWT as the output of the introspection =
endpoint as well.
>>=20
>> -- Justin
>>=20
>> On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote:
>>> Hi Justin,
>>>=20
>>> I refered to the data format used at the AS-PR interface. According =
to your description, you use JSON objects there. What data does such an =
object contain? Is this any different from a JSON Web Token (leaving =
aside digital signatures and encryption)?
>>>=20
>>> regards,
>>> Torsten.
>>>=20
>>> Am 18.04.2012 22:01, schrieb Justin Richer:
>>>> Not all implementations in the field that do this are using JWTs as =
the tokens. Ours in particular used a random blob with no structured =
information in it. The endpoint returned a JSON object.
>>>>=20
>>>> -- Justin
>>>>=20
>>>> On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote:
>>>>> Hi all,
>>>>>=20
>>>>> is there enough experience in the field with such an interface to =
standardize it?
>>>>>=20
>>>>> I would expect such an endpoint to return the same payload, which =
is carried in a JSON Web Token. So once we designed the JSON Web Tokens =
content, designing the AS-PR interface could be the next logical step =
(after the next re-charting).
>>>>>=20
>>>>> regards,
>>>>> Torsten.
>>>>>=20
>>>>> Am 16.04.2012 21:04, schrieb Justin Richer:
>>>>>>=20
>>>>>>>> OK, but with SWD and discovery off the table, can this now be
>>>>>>>> considered to be within that manageable number instead?
>>>>>>> We wanted to keep the # of WG items to approximately 5.  Once we =
finish
>>>>>>> some of these items and get them off our plate we could roll new =
items
>>>>>>> onto the plate, theoretically.
>>>>>>>=20
>>>>>>=20
>>>>>> That's definitely true going forward, but what I was saying is =
that the number of items under consideration is now down to 4, with SWD =
moving to the Apps group. I was proposing that the whole introspection =
endpoint and general AS-PR connection could be this group's fifth =
starting document.
>>>>>>=20
>>>>>> -- Justin


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


From eve@xmlgrrl.com  Sun Apr 22 13:50:14 2012
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 F187921F853B for ; Sun, 22 Apr 2012 13:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.293
X-Spam-Level: 
X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306,  URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajnNz9LkMI3W for ; Sun, 22 Apr 2012 13:50:14 -0700 (PDT)
Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6C56C21F8534 for ; Sun, 22 Apr 2012 13:50:14 -0700 (PDT)
Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q3MKoBiE017827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Apr 2012 13:50:11 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Eve Maler 
In-Reply-To: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net>
Date: Sun, 22 Apr 2012 13:50:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E740085-268C-42E7-AE5C-85760D60E1B6@xmlgrrl.com>
References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1257)
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] IIW and OAuth
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: Sun, 22 Apr 2012 20:50:15 -0000

I will be at IIW on Tuesday, at least part of Wednesday, and Thursday. =
Some UMAnitarians have suggested proposing an IIW session to collect =
OAuth AS/RS separation use cases. I'm happy to champion that on the =
Tuesday if there's interest.

Also, we're planning to have an UMA "open meeting" during a couple of =
Thursday afternoon blocks, if any folks on this list would like to join =
in. (Thursday is "Yukon day", which is roughly the personal data =
ecosystem day. I can't recall how it got this moniker.)

	Eve

On 16 Apr 2012, at 4:55 AM, Hannes Tschofenig wrote:

> Hi guys,=20
>=20
> I was wondering how many of you will be at the upcoming IIW in =
Mountain View (or for some other event). IIW will run from Tuesday (May =
1st) to Thursday (May 3rd).=20
>=20
> I thought it might be good to useful to get together on the Friday =
after the IIW event for a OAuth breakfast chat.
> I am sure that there are still a couple of topics that require =
brainstorming. =20
>=20
> Drop me a message if you are able and interested.
>=20
> Ciao
> Hannes
>=20
> PS: Please do not forget to read the Assertion specs so that we can =
get them out of the door.=20
> (And thanks to those who have already read them.)
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


From bcampbell@pingidentity.com  Mon Apr 23 05:36:18 2012
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 10C7F21F84C3 for ; Mon, 23 Apr 2012 05:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.956
X-Spam-Level: 
X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=0.020,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN6Laumbj0JX for ; Mon, 23 Apr 2012 05:36:17 -0700 (PDT)
Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECF921F8587 for ; Mon, 23 Apr 2012 05:36:16 -0700 (PDT)
Received: from mail-vb0-f44.google.com ([209.85.212.44]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKT5VMuXq5SPBdfg1GCYNXfAFJO+ggakaG@postini.com; Mon, 23 Apr 2012 05:36:16 PDT
Received: by vbbez10 with SMTP id ez10so9397182vbb.31 for ; Mon, 23 Apr 2012 05:36:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=vb1WQ1bFNcqJUoj9VGe0l3IkGCdKElikrGlRtlf/0kI=; b=JP2IMnlfJ5+VMbPfKwv0POHSiBLuLo4ImAoulDmkUgMgZ9Gn6Rhz7eVvmraC/Yzzao i4aX6sYj/UiFkri0h6gsDbCQyJ10jHeHV0YVmX+loxTbOFbBx+NlrTn7omilX5TjRF0Z yrDcvpG3YQ85LQtVZ/+VBeNxbnXS3HRRBQjrnBZ4rWyjrbOkhCkRq7+K9Zr3hzK/mIQC 9HyrZmTEWZdDFl0fsHlGNf/1X0IDFBW0/2oOqzSFJjRXeDkY/2Eh2zP3Kdi6wKudOWnB HNdmdzNuBmm5wWrspGWwoc9p+s/ZtGE/1UN2slb4dxXEdokzannWCmW4042POeMMG8/K LumQ==
Received: by 10.52.65.69 with SMTP id v5mr13032949vds.14.1335184567103; Mon, 23 Apr 2012 05:36:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.38.104 with HTTP; Mon, 23 Apr 2012 05:35:36 -0700 (PDT)
In-Reply-To: <5710F82C0E73B04FA559560098BF95B1250E8BAD72@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <5710F82C0E73B04FA559560098BF95B1250DE5716F@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>  <5710F82C0E73B04FA559560098BF95B1250E8BAD72@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
From: Brian Campbell 
Date: Mon, 23 Apr 2012 06:35:36 -0600
Message-ID: 
To: "Zeltsan, Zachary (Zachary)" 
Content-Type: multipart/alternative; boundary=20cf307f344ad4f2af04be57e1b1
X-Gm-Message-State: ALoCoQmXSx+h8V1hXEXvaet9UA/oKYXPAyRH3o4U7GOOHOytaMLSa18Dk7N9I4zFcvLle2zOcmp0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] WGLC on Assertion Drafts
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, 23 Apr 2012 12:36:18 -0000

--20cf307f344ad4f2af04be57e1b1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Just a note (to myself as much as anything) that that same text is also in
=A76.2, =A76.3 & =A76.4 and should updated for all occurrences.

On Fri, Apr 13, 2012 at 12:55 PM, Zeltsan, Zachary (Zachary) <
zachary.zeltsan@alcatel-lucent.com> wrote:

> Chuck,****
>
> ** **
>
> The intent is clear. Perhaps the following change would clarify the text:=
*
> ***
>
> Old: The Authorization Server MUST validate the assertion in order
> to establish a mapping between the Issuer and the secret used to generate
> the assertion.****
>
> New: The Authorization Server MUST validate the assertion=92s signature i=
n
> order to verify the Issuer of the assertion.****
>
> ** **
>
> Zachary****
>
> ** **
>
> ** **
>
> *From:* Chuck Mortimore [mailto:cmortimore@salesforce.com]
> *Sent:* Friday, April 13, 2012 1:20 PM
> *To:* Zeltsan, Zachary (Zachary); Tschofenig, Hannes (NSN - FI/Espoo);
> oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] WGLC on Assertion Drafts****
>
> ** **
>
> Hi Zachary =96 sorry about the delay in responding.
>
> Perhaps the language is a bit confusing =96 let me explain the intent and
> see if it makes sense and if you have a recommendation on how it could be
> made clearer.
>
> All this is really saying is that the Authorization server must validate
> the signature to make sure the Issuer is who they say they are.   The
> authorization server would use the Issuer as it=92s mechanism for looking=
 up
> either the shared secret for an HS256 or the public key for RS256.   It
> then checks the signature, and proves to itself that the generator of the
> assertion had possession of the expected keying material and identified
> itself as the issuer.
>
> Feedback welcome
>
> -cmort
>
> On 4/5/12 1:33 PM, "Zeltsan, Zachary (Zachary)" <
> zachary.zeltsan@alcatel-lucent.com> wrote:****
>
> Hello,
>
> The draft http://tools.ietf.org/html/draft-ietf-oauth-assertions-01,
> section 6.1 has the following requirement:
>
> The Authorization Server MUST validate the assertion in order to
>       establish a mapping between the Issuer and the secret used to
> generate the assertion.
>
> I thought that checking a signature is a part of the assertion validation=
,
> which cannot be done without knowing the mapping between the issuer and t=
he
> secret used to generate the assertion.
> It appears that the quoted text requires validation of the assertion prio=
r
> to checking the signature.
> What am I missing?
>
> Zachary
>
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
> *On Behalf Of *Tschofenig, Hannes (NSN - FI/Espoo)
> *Sent:* Thursday, April 05, 2012 10:47 AM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] WGLC on Assertion Drafts
>
> Hi all,
>
> this is a Last Call for comments on these three documents:
>
> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10
>
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-01
>
> http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02
>
> Please have your comments in no later than April 23rd.
>
> Do remember to send a note in if you have read the document and have no
> other comments other than "it=92s ready to go" - we need those as much as=
 we
> need "I found a problem".
>
> Thanks!
>
> Hannes & Derek****
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--20cf307f344ad4f2af04be57e1b1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Just a note (to myself as much as anything) that that same text is also in =
=A76.2, =A76.3 & =A76.4 and should updated for all occurrences.

=

On Fri, Apr 13, 2012 at 12:55 PM, Zeltsan, Zacha=
ry (Zachary) <zachary.zeltsan@alcatel-lucent.com> wrote:



Chuck,



=A0
The intent i=
s clear. Perhaps the following change would clarify the text:=




Old: The Authorization Server MUST val=
idate the assertion in order to=A0establish a mapping between the Issuer an=
d the secret used to generate the assertion.



New: The Authorization Server MUST val=
idate the assertion=92s signature in order to=A0verify the Issuer of the as=
sertion.



=A0
Zachary=




=A0
=A0



From: Chuck Mortimore [mailto:cmortimore@salesforce.com] 


Sent: Friday, April 13, 2012 1:20 PM
To: Zeltsan, Zachary =
(Zachary); Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org
Subject: Re: [OAUTH-W=
G] WGLC on Assertion Drafts



=A0=

Hi =
Zachary =96 sorry about the delay in responding.



Perhaps the language is a bit confusing =96 let me explain the intent a=
nd see if it makes sense and if you have a recommendation on how it could b=
e made clearer.

All this is really saying is that the Authorization =
server must validate the signature to make sure the Issuer is who they say =
they are. =A0=A0The authorization server would use the Issuer as it=92s mec=
hanism for looking up either the shared secret for an HS256 or the public k=
ey for RS256. =A0=A0It then checks the signature, and proves to itself that=
 the generator of the assertion had possession of the expected keying mater=
ial and identified itself as the issuer.



Feedback welcome

-cmort 

On 4/5/12 1:33 PM, "Zeltsan=
, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> wrote=
:



Hello,<=
br>=A0
The draft http://tools.ietf.org/html/draft-ietf-=
oauth-assertions-01, section 6.1 has the following requirement:



The Authorization Server MUST validate the asserti=
on in order to
=A0=A0=A0=A0=A0=A0establish a mapping between the Issuer =
and the secret used to generate the assertion.


=A0
I thought that checking a signature is a part of the assertion valid=
ation, which cannot be done without knowing the mapping between the issuer =
and the secret used to generate the assertion.
It appears that the quote=
d text requires validation of the assertion prior to checking the signature=
.


What am I missing?
=A0
Zachary
=A0

=
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behal=
f Of Tschofenig, Hannes (NSN - FI/Espoo)


Sent: Thursday, April 05, 2012 10:47 AM
To: oauth@ietf.org
Subject:=
 [OAUTH-WG] WGLC on Assertion Drafts

Hi all, 



this is a Last Call for comments on these thre=
e documents:



http://tools.ietf.org/html/draf=
t-ietf-oauth-saml2-bearer-10



http://tools.ietf.org/html/draft-=
ietf-oauth-assertions-01



http://tools.ietf.org/html/draft-=
ietf-oauth-urn-sub-ns-02



Please have your comments in no later than Apr=
il 23rd.



Do remember to send a note in if you have read=
 the document and have no other comments other than "it=92s ready to g=
o" - we need those as much as we need "I found a problem".


Thanks!



Hannes & Derek

=
_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--20cf307f344ad4f2af04be57e1b1--

From bcampbell@pingidentity.com  Mon Apr 23 05:42:11 2012
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 3D8A021F861E for ; Mon, 23 Apr 2012 05:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.958
X-Spam-Level: 
X-Spam-Status: No, score=-5.958 tagged_above=-999 required=5 tests=[AWL=0.018,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3J-d-QpRLeDT for ; Mon, 23 Apr 2012 05:42:10 -0700 (PDT)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 59CAD21F8611 for ; Mon, 23 Apr 2012 05:42:10 -0700 (PDT)
Received: from mail-vx0-f177.google.com ([209.85.220.177]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKT5VOIZvCmKOunPi4ty9speXEEOUZagdT@postini.com; Mon, 23 Apr 2012 05:42:10 PDT
Received: by vcbf13 with SMTP id f13so11075236vcb.8 for ; Mon, 23 Apr 2012 05:42:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=zoHc0mjXUYo2fBpxg9F7e7DBcSsZSvsm+LOAELvBoeE=; b=UOIcnlSA85JDGJIhnW+GVhwbA8JaFeluamOS4Blgk2YcvXUCeox4jZO8Z6Qu1MXAQU DnNzX04nd0Fff6gd71oTpnhLtWFwzpYoMfdP3su+bytOT/wTqXIs5kjrAh3G83ncTgb6 TcuA7RRonz3IqBkp3kwiYyq+UU5ISLtbj9d7PpMKppcoHPuOdqLtB/jdju5YIYOx5Mww v2pS4TnjgxZLiWrzGQW81NAq8O2Rn6nodnnuWMUkWgT8S7DTvknN7L79xatoVfTnd18h PVY0SgTURIlMlszBvq3dsqske9AMeb6BP8WeOZQy3SN08U7EtzKJQlOYkKrevUUoNis2 O0sw==
Received: by 10.220.117.203 with SMTP id s11mr15531931vcq.33.1335184929076; Mon, 23 Apr 2012 05:42:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.38.104 with HTTP; Mon, 23 Apr 2012 05:41:38 -0700 (PDT)
From: Brian Campbell 
Date: Mon, 23 Apr 2012 06:41:38 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=485b39618d1268370504be57f7c3
X-Gm-Message-State: ALoCoQkek8bi+IIFxIzAfL85Y01aUa8p73212U449xTuR8kxP8luKZx1yHYEuweC5ApI/uELcqAU
Subject: [OAUTH-WG] draft-ietf-oauth-assertions WGLC comment
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, 23 Apr 2012 12:42:11 -0000

--485b39618d1268370504be57f7c3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=A76.1 on Client authentication* has the following requirement,

"The Principal MUST identify an authorized accessor. If the assertion is
self-issued, the Principal SHOULD be the client_id."

which doesn't really make sense for client authentication.  The
self-issuedness of the assertion should have no bearing on the principal
(rather the issuer) and, when used for client authentication, the principal
should always represent the client.  I believe the bullet should instead
say,

"The Principal SHOULD be the client_id."



* http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-6.1

--485b39618d1268370504be57f7c3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=A76.1 on Client authentication* has the following requirement, 

&qu=
ot;The Principal MUST identify an authorized accessor.  If the assertion is=
 self-issued, the Principal SHOULD be the client_id."

which doe=
sn't really make sense for client authentication.=A0 The self-issuednes=
s of the assertion should have no bearing on the principal (rather the issu=
er) and, when used for client authentication, the principal should always r=
epresent the client.=A0 I believe the bullet should instead say,



"The Principal SHOULD be the client_id."



* http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-6.1

--485b39618d1268370504be57f7c3--

From bcampbell@pingidentity.com  Mon Apr 23 05:58:38 2012
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 E552D21F84E4 for ; Mon, 23 Apr 2012 05:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.959
X-Spam-Level: 
X-Spam-Status: No, score=-5.959 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8iH8St1jLEi for ; Mon, 23 Apr 2012 05:58:38 -0700 (PDT)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0763D21F849B for ; Mon, 23 Apr 2012 05:58:37 -0700 (PDT)
Received: from mail-vb0-f50.google.com ([209.85.212.50]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKT5VR/ZAeNGFjkS6+q7cbLh8EVY5+Feap@postini.com; Mon, 23 Apr 2012 05:58:38 PDT
Received: by vbnl22 with SMTP id l22so11812378vbn.37 for ; Mon, 23 Apr 2012 05:58:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=3hP75BqQ6q7PJugUEJ9YMOA1R40S68WtGz8LPGVglcE=; b=B1MN2ri7nkedHgmQXoKpNc6EVxhe/pnA/2e/iZlcTqjK4op0qcdNgMYPqtVRkA+fxz z0yf13WUDaxoxXWkdbXxxYlI81VcSSOg5y4TMr0hu/7vY1kO/5K6K0vrTSzydkrZ8SrA OYs23MZlAz+o92AUmsw22pD7X+uwl67Sugg6OvEsHqO6+qBiXQ7DNgoTF7+W4PSqjKY4 zuaQVdu1lLJEfd8c8upyWF2soJeGDNEZQ3FGO8Bf5O9JMiwqeWIwyuHeKJfjnnt0JERL q/bqu0HQg7bcq8cG14VXrT5Q33mheOwscjqs65I8xkflcsI9s/04rfdLYu93hfi9ENU2 5ETw==
Received: by 10.52.65.170 with SMTP id y10mr8634938vds.48.1335185916854; Mon, 23 Apr 2012 05:58:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.38.104 with HTTP; Mon, 23 Apr 2012 05:58:06 -0700 (PDT)
From: Brian Campbell 
Date: Mon, 23 Apr 2012 06:58:06 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=20cf307f3af248811c04be5832b6
X-Gm-Message-State: ALoCoQnaAT/18+c8qRcjbOkMNyZly+yK10INXTjdXO+HZL3LRvEN7BAPTS2xT/mwGUE5JQJVpkCY
Subject: [OAUTH-WG] draft-ietf-oauth-assertions WGLC comment II
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, 23 Apr 2012 12:58:39 -0000

--20cf307f3af248811c04be5832b6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The third paragraph of =A74.1* has, "The following section defines the use =
of
assertions as client credentials as an extension of Section
3.2o=
f
OAuth 2.0 [
I-D.ietf.oauth-v2]."
However the Section 3.2 link is to #section-3.2 in the assertions document
(which doesn't exist and is the wrong document) rather than to the core
OAuth document.

I think it should probably reference =A72.3 (rather than 3.2) of oauth-v2**
and the link should be fixed or removed.



* http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.1
** http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.3

--20cf307f3af248811c04be5832b6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The third paragraph of =A74.1* has, "The following section defines the=
 use of assertions as client
   credentials as an extension of Section 3.2 of OAuth 2.0
   [I-D.ietf.oauth-v2]." However the Section 3.2 =
link is to #section-3.2 in the assertions document (which doesn't exist=
 and is the wrong document) rather than to the core OAuth document.=A0 



I think it should probably reference =A72.3 (rather than 3.2) of oauth-=
v2** and the link should be fixed or removed.



* http:=
//tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.1


** http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.3


--20cf307f3af248811c04be5832b6--

From bcampbell@pingidentity.com  Mon Apr 23 06:17:15 2012
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 6AE4A21F85E3 for ; Mon, 23 Apr 2012 06:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.46
X-Spam-Level: 
X-Spam-Status: No, score=-5.46 tagged_above=-999 required=5 tests=[AWL=-0.484,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_12=1, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQzlrU97v6qa for ; Mon, 23 Apr 2012 06:17:14 -0700 (PDT)
Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with ESMTP id 98D1D21F85DF for ; Mon, 23 Apr 2012 06:17:14 -0700 (PDT)
Received: from mail-vx0-f173.google.com ([209.85.220.173]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKT5VWWQRP+mR2DGIZl3o9a3EphqQqJDzI@postini.com; Mon, 23 Apr 2012 06:17:14 PDT
Received: by vcbfl11 with SMTP id fl11so10697773vcb.32 for ; Mon, 23 Apr 2012 06:17:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=1/dyC495oo8cBq4ibgBdKjA9XqZgcXtVrdhrBvV0gFc=; b=c9ZYRC1GA+qqLHlSY3ix/foy1t7/5TIuwP5F3nXTb42dcvfktcLKrd5J20O+xwoW2M XyHj3x7NFrUZmNtkOrVBBEJt+3rZlrHQOaMO+RydSNyKeHKDHQMrmaILpSzILerwMtIK 6t14JsJKAbk8s8N99xx8XE0l4yrGs01zxLTJ0EiKPBnftJfIYSZPSmUBS7Gim6wUqHqW TAb6OmrvyAWkk3nU3kLttMSQsTd+dpNvhAbajTGjYthkFIYbNGKeaW8KqkTVvwBL7gdr DAKg0kavedhkH32JkTD+DdK3eldD+sLxWSx9DViEg/Ld3TfK9kIIfmvItcRpnGJPVFI4 Gv0w==
Received: by 10.52.90.175 with SMTP id bx15mr10059710vdb.31.1335187032935; Mon, 23 Apr 2012 06:17:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.38.104 with HTTP; Mon, 23 Apr 2012 06:16:42 -0700 (PDT)
From: Brian Campbell 
Date: Mon, 23 Apr 2012 07:16:42 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=20cf3071c9cece8c1a04be5874ce
X-Gm-Message-State: ALoCoQmpBNT31SqkNptppRKCEfPkWpTG6Ojmsww5yLGkr3yrZaUL+YYcjWDAls30MOqcGrrzprg/
Subject: [OAUTH-WG] draft-ietf-oauth-assertions WGLC comment III
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, 23 Apr 2012 13:17:15 -0000

--20cf3071c9cece8c1a04be5874ce
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The following text appears in =A74.1 and =A74.2 defining (describing becaus=
e
it's already defined in core?) the client_id parameter,

"client_id OPTIONAL. The client identifier as described in Section
3of
OAuth 2.0 [
I-D.ietf.oauth-v2
]."

The section reference needs to be changed to 2 rather than 3 and the link
is currently to the wrong document.

I'd also argue that the text should be removed from =A74.2 because it's usa=
ge
is orthogonal to the abstract use of assertions as authorization grants
which is what the section is defining.

--20cf3071c9cece8c1a04be5874ce
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The following text appears in =A74.1 and =A74.2 defining (describing becaus=
e it's already defined in core?) the client_id parameter,



"client_id  OPTIONAL.  The client identifier as described in Se=
ction 3
      of OAuth 2.0 [I-D.ietf.oauth-v2]."

T=
he section reference needs to be changed to 2 rather than 3 and the link is=
 currently to the wrong document.



I'd also argue that the text should be removed from =A74.2 because =
it's usage is orthogonal to the abstract use of assertions as authoriza=
tion grants which is what the section is defining.




--20cf3071c9cece8c1a04be5874ce--

From ve7jtb@ve7jtb.com  Mon Apr 23 07:19:52 2012
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 0952521F8661 for ; Mon, 23 Apr 2012 07:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.174
X-Spam-Level: 
X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+q66GJkA1Vc for ; Mon, 23 Apr 2012 07:19:50 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9221F864A for ; Mon, 23 Apr 2012 07:19:50 -0700 (PDT)
Received: by qaea16 with SMTP id a16so1508538qae.10 for ; Mon, 23 Apr 2012 07:19:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=ChCMdGzHKxNBSiVVcQem/PL0yeOf1KflLExr7zK3OdI=; b=gdBZg+N8mxnENY45s0r+j2MMIiAbSelRvGjZb8PGK+yCnR6ip4SvHb0H1FD0JCa7+e 7JVXGY+AVlZLnU/FYE4wZ6sgNfoh5ACkSMRPKt1n9OHzYCt2p73x27WYyAKghynAIgVG bD5mqYNgxjFsRrEffO/Z1bNq7Iqjwwmkn5FGsWH+gsmlD2684nTpBRMVxj38KzihRXcu 7bz85wKxG00eqYLjCRsVK4aWQ1gDD1xt/0bKkm38hfn3SSu3diXKquKRqi75TCrfPVKR g1cwEVhOHEccIxsbP2GXXKEalk8mVusgwtnG1h3ziCVq3ljIvnoEh239otrcKyD0qYd/ Fm4w==
Received: by 10.224.180.212 with SMTP id bv20mr3344124qab.4.1335190789673; Mon, 23 Apr 2012 07:19:49 -0700 (PDT)
Received: from [192.168.1.213] (190-20-21-61.baf.movistar.cl. [190.20.21.61]) by mx.google.com with ESMTPS id hv18sm1402914qab.19.2012.04.23.07.19.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 07:19:47 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_A0957514-3148-484B-91E4-762190898BC7"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: 
Date: Mon, 23 Apr 2012 11:19:21 -0300
Message-Id: <18D09FE1-A118-48C3-AC45-4DF79C325C28@ve7jtb.com>
References: <693A5F68-9F51-452C-B684-2A891133F875@gmx.net> <4F885BF9.2080307@mitre.org> <4E1F6AAD24975D4BA5B1680429673943664668FF@TK5EX14MBXC283.redmond.corp.microsoft.com> <4F88713C.6070309@mitre.org>  <4F8C6D43.2030701@mitre.org> <4F8F1B9F.1040302@lodderstedt.net> <4F8F1D94.4090208@mitre.org> <4F8F1F9C.7020008@lodderstedt.net> <4F8F22C4.6000900@mitre.org> <4F9059F5.1050705@lodderstedt.net> 
To: Eve Maler 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQksMzNfBiye4TgY7P5Y9KS+RS7S4QquDUdT9KPg3Hk7Mv0erW89yGJOi+67oTcn15+klr7o
Cc: Derek Atkins , "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
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, 23 Apr 2012 14:19:52 -0000

--Apple-Mail=_A0957514-3148-484B-91E4-762190898BC7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Eve,

A number of us want to hold a session on the Tuesday of IIW to discuss =
the various options, that people have built.

UMA is one of the more advanced ones, but we also have Ping, MITRE,  =
AOL, and others.

There is a fair amount of overlap between them.

If the AS RS work is not included in the charter it will probably =
continue independently until the next rechartering.

John B.


On 2012-04-22, at 5:43 PM, Eve Maler wrote:

> Once again, you may want to look at the UMA core I-D to see how it =
defines an AS/RS interface:
>=20
> http://tools.ietf.org/html/draft-hardjono-oauth-umacore-04
> (see particularly Section 3.3)
>=20
> It uses what is by now a very common token introspection pattern to =
have the RS get the AS's crucial help in validating the token that was =
presented to it. UMA has a mandatory-to-implement token profile called =
"bearer", which treats the token introspection endpoint as a run-time =
way to get the content associated with the token blob. Obviously, what's =
returned from that call is currently UMA-specific (and in fact this =
class of profiles is called "UMA token profiles"). Note that the call to =
the token introspection endpoint must be accompanied by an OAuth token =
in the header because the endpoint is OAuth-protected. (Yes, it's =
turtles all the way down...) We haven't yet defined an "UMA JWT token =
profile", but that's the next logical step.
>=20
> This type of introspection functionality could be called a narrow =
definition of the AS/RS interface requirement. To make it possible to =
have the AS and RS live in completely separate domains potentially =
controlled by different parties (a broad definition), a number of other =
elements would ultimately be required. This is where UMA's entire =
"protection API" may be interesting to look at, since it has been =
demonstrated to apply to typical OAuth use cases (single resource owner) =
as well as access management use cases (resource owner and requesting =
party are different).
>=20
> 	Eve
>=20
> On 19 Apr 2012, at 11:31 AM, Torsten Lodderstedt wrote:
>=20
>> Hi Justin,
>>=20
>> In my opinion, the OpenID Connect introspection/checkid endpoint is a =
convenience function for clients (not resource servers) unable to =
decrypt id tokens and validate their signatures. I'm not convinced this =
function is needed, that's why I proposed to drop it.
>>=20
>> The AS-PR endpoint servers a different purpose, as it allows to =
implement handle-based token designs. The AS just creates simple token =
(e.g. a random number), which is very small and does not need to be =
encrypted or signed. This might result in simple designs. On the other =
hand, the PR needs to lookup authz data as part of the request =
implementation, which might have a negative impact on performance and =
scalability. That's where self-contained tokens, such as JWT have their =
merits.
>>=20
>> I don't think one would combine self-contained tokens with an AS-PR =
endpoint. Or is this the case in any existing implementations?
>>=20
>> The point I wanted to make is: no matter how the resource server =
acquires authz data (as token content/JWT or via request to another =
AS-PR endpoint), the authz data will be the same. And as part of the JWT =
standardization, we will identify this data and specify a JSON format to =
represent it. The same representation could be used at the AS-PR =
endpoint as well.
>>=20
>> regards,
>> Torsten.
>>=20
>> Am 18.04.2012 22:23, schrieb Justin Richer:
>>> I think we might be crossing wires about input to the token =
introspection endpoint vs. output from it.
>>>=20
>>> In OpenID Connect, you send a JWT in, and get back a JSON object =
that represents the Claims bit of the JWT.
>>>=20
>>> In our implementation (and I think both Ping and AOL's), you send in =
an arbitrary token (with no proscribed format) and get back a JSON =
object with different pieces in it. Ours included a list of scopes and =
an expiration timestamp, others did different things, like audience and =
issuer, as part of the return.
>>>=20
>>> The point I was trying to make is that the information returned from =
the AS-PR interface isn't necessarily embedded inside of the token used =
to call that interface. In OpenID Connect, it is, and the CheckID =
endpoint just unwraps the JWT for you. In the larger case, what's really =
going on is that the PR presents a token that it's not sure what it's =
good for and gets back something that answers that question. Since a JWT =
Claims section can be an arbitrary JSON object (for all intents and =
purposes), you could use a JWT as the output of the introspection =
endpoint as well.
>>>=20
>>> -- Justin
>>>=20
>>> On 04/18/2012 04:10 PM, Torsten Lodderstedt wrote:
>>>> Hi Justin,
>>>>=20
>>>> I refered to the data format used at the AS-PR interface. According =
to your description, you use JSON objects there. What data does such an =
object contain? Is this any different from a JSON Web Token (leaving =
aside digital signatures and encryption)?
>>>>=20
>>>> regards,
>>>> Torsten.
>>>>=20
>>>> Am 18.04.2012 22:01, schrieb Justin Richer:
>>>>> Not all implementations in the field that do this are using JWTs =
as the tokens. Ours in particular used a random blob with no structured =
information in it. The endpoint returned a JSON object.
>>>>>=20
>>>>> -- Justin
>>>>>=20
>>>>> On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote:
>>>>>> Hi all,
>>>>>>=20
>>>>>> is there enough experience in the field with such an interface to =
standardize it?
>>>>>>=20
>>>>>> I would expect such an endpoint to return the same payload, which =
is carried in a JSON Web Token. So once we designed the JSON Web Tokens =
content, designing the AS-PR interface could be the next logical step =
(after the next re-charting).
>>>>>>=20
>>>>>> regards,
>>>>>> Torsten.
>>>>>>=20
>>>>>> Am 16.04.2012 21:04, schrieb Justin Richer:
>>>>>>>=20
>>>>>>>>> OK, but with SWD and discovery off the table, can this now be
>>>>>>>>> considered to be within that manageable number instead?
>>>>>>>> We wanted to keep the # of WG items to approximately 5.  Once =
we finish
>>>>>>>> some of these items and get them off our plate we could roll =
new items
>>>>>>>> onto the plate, theoretically.
>>>>>>>>=20
>>>>>>>=20
>>>>>>> That's definitely true going forward, but what I was saying is =
that the number of items under consideration is now down to 4, with SWD =
moving to the Apps group. I was proposing that the whole introspection =
endpoint and general AS-PR connection could be this group's fifth =
starting document.
>>>>>>>=20
>>>>>>> -- Justin
>=20
>=20
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_A0957514-3148-484B-91E4-762190898BC7
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
MzE0MTkyMVowIwYJKoZIhvcNAQkEMRYEFOARMYRUsRmaCGC694d3E6MsdZ6GMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
ADX0AigEXU5irul4sMqllp8f0OJG6fiEJufbUFCyt3Gzns1bNh0auscCJZcKWvpV2jQ74U9q6q8M
frjAA+u0O/Ga4yhKsuK7vxu/LPZBsUKwxSHOUjI8BJi2QPjFfcja2+ZR8YlNuY68/WSvuSBSisRT
y8sAOWQKa0KQ2kLvPP192rShXtFrDZ+j0C9HMnbYcvkxrIq5OdQzM3G6mDOVlk+okrqzGkTI1OKu
hriuuyOfIcR4R5stYQ5XiswS/iNSahD8K67KNU/qQLtUOU8/a5N/w9JQF3wrXFsZrBSPkWyhDWWM
tZtv4cO5jKmyRSjRkeI9Tj8etCaAYIUDjSgug7MAAAAAAAA=

--Apple-Mail=_A0957514-3148-484B-91E4-762190898BC7--

From ve7jtb@ve7jtb.com  Mon Apr 23 07:23:03 2012
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 A1AD721F8675 for ; Mon, 23 Apr 2012 07:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.149
X-Spam-Level: 
X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-fGSOHvgArz for ; Mon, 23 Apr 2012 07:23:02 -0700 (PDT)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id B1DC721F8674 for ; Mon, 23 Apr 2012 07:23:02 -0700 (PDT)
Received: by qafi31 with SMTP id i31so1986780qaf.15 for ; Mon, 23 Apr 2012 07:23:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=d5Yqk8GFS0sMd3Y9lxOxfDXp8e3is72w/RY2OtFTpKg=; b=PUAQBONYHtjHN50EAraK1dF5u3TPrIyBF1j01Xmdf0REFvz9KzPufby5/eGzzwZehp UHyEWDXOTIFtpmTgecZs8KbxKWU3lck/eolgpMRABfMw9uTxgAYjzk9H8yIvvRBHCLhW RjhejNYL87DkoGDGOnSsxAdH5m2X5N+MwXLWV3fPtaqlaaxJI/jfdkJjlVEjeRN9+KI+ 3PX8aJI+6V66aaLVNOF7OJcipHBRuIzA4KsU0CGiKh/hJYXuOa8zC6KxOEwxpgnPzywp tPCELjy5lc5+Nut4lrE4c+e99Z9ZOMtGCmEX+5/p8CiokeU9Dp0jUJxZk+HKo/THV6GM aSlA==
Received: by 10.229.136.208 with SMTP id s16mr4182245qct.50.1335190981921; Mon, 23 Apr 2012 07:23:01 -0700 (PDT)
Received: from [192.168.1.213] (190-20-21-61.baf.movistar.cl. [190.20.21.61]) by mx.google.com with ESMTPS id o7sm21897554qan.15.2012.04.23.07.22.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 07:23:00 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_7CB63CAA-66CE-4B61-9A4B-6982CAA05006"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley 
In-Reply-To: <7E740085-268C-42E7-AE5C-85760D60E1B6@xmlgrrl.com>
Date: Mon, 23 Apr 2012 11:22:51 -0300
Message-Id: 
References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> <7E740085-268C-42E7-AE5C-85760D60E1B6@xmlgrrl.com>
To: Eve Maler 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQk6xSuvglwnGNLqHrL5HF8ZtGmooJ3NIlM486fXO54s/2xmBxo8g5qna9wXsuR3yVMjWEhX
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] IIW and OAuth
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, 23 Apr 2012 14:23:03 -0000

--Apple-Mail=_7CB63CAA-66CE-4B61-9A4B-6982CAA05006
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I was talking to Phil last week and Thursday is open IIW time like =
Tuesday - Wednesday.  I had thought it was a Yukon day as well, but that =
is apparently not happening.

I think there is also a OASIS trust elevation TC thing Marry is trying =
to do on Thursday as well at IIW.

John B.
On 2012-04-22, at 5:50 PM, Eve Maler wrote:

> I will be at IIW on Tuesday, at least part of Wednesday, and Thursday. =
Some UMAnitarians have suggested proposing an IIW session to collect =
OAuth AS/RS separation use cases. I'm happy to champion that on the =
Tuesday if there's interest.
>=20
> Also, we're planning to have an UMA "open meeting" during a couple of =
Thursday afternoon blocks, if any folks on this list would like to join =
in. (Thursday is "Yukon day", which is roughly the personal data =
ecosystem day. I can't recall how it got this moniker.)
>=20
> 	Eve
>=20
> On 16 Apr 2012, at 4:55 AM, Hannes Tschofenig wrote:
>=20
>> Hi guys,=20
>>=20
>> I was wondering how many of you will be at the upcoming IIW in =
Mountain View (or for some other event). IIW will run from Tuesday (May =
1st) to Thursday (May 3rd).=20
>>=20
>> I thought it might be good to useful to get together on the Friday =
after the IIW event for a OAuth breakfast chat.
>> I am sure that there are still a couple of topics that require =
brainstorming. =20
>>=20
>> Drop me a message if you are able and interested.
>>=20
>> Ciao
>> Hannes
>>=20
>> PS: Please do not forget to read the Assertion specs so that we can =
get them out of the door.=20
>> (And thanks to those who have already read them.)
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_7CB63CAA-66CE-4B61-9A4B-6982CAA05006
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw
ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh
cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew
HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3
NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU
BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ
ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93
rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe
nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa
hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw
26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc
ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz
9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh
ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl
N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC
IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj
b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu
IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC
AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg
YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh
dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB
BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr
BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu
Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc
0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d
NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT
0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC
Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI
hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln
aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h
cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD
teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA
o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX
fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6
5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w
CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd
gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw
JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G
CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu
Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU
MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p
bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy
dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl
Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg
UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR
BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy
eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA
A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE
4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn
JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1
z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7
qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ
3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E
/ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9
tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH
jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK
qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO
AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQy
MzE0MjI1MlowIwYJKoZIhvcNAQkEMRYEFBhOsATOGU2VSgFORTDm+0AnLqVcMIGkBgkrBgEEAYI3
EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL
EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL
MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB
AHa/TSvuc5lPM/26gjuvgXB7Ij4NBiQIMe8r1X+VxC9ZpDOKYu2cJYVLmNTbuQNpeEMVsb0zJVxL
jgP0ZqQB6NVSuMs74Qabg+kvomYBSUQe9t6EWUkA9px9p5L/tqkBgWR+neNucJQzmYf+RGzhF/uC
WRuGUdebYgU0BaMedh29V7OjQe5437VkrcV9wiI8OhEyboKISj28/G1hrtky/G2sVur/a9JhXIey
FaBvVA1xuczTSPEjkN4UpXHqD4QUtU/P1PY4ULgY1gLkdHZft+ZMZQfoxdSzGLcGr7mZHYIcgYn5
A1GoAGDKinS1Qy3rEKQeLlbFre8T5sw4Boon7W0AAAAAAAA=

--Apple-Mail=_7CB63CAA-66CE-4B61-9A4B-6982CAA05006--

From jricher@mitre.org  Mon Apr 23 07:41:09 2012
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 7B47F21F8623 for ; Mon, 23 Apr 2012 07:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.172
X-Spam-Level: 
X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awqXnIFbepFf for ; Mon, 23 Apr 2012 07:41:08 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABD321F85B4 for ; Mon, 23 Apr 2012 07:41:07 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 60FF621B006F for ; Mon, 23 Apr 2012 10:41:05 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5A62821B0066 for ; Mon, 23 Apr 2012 10:41:05 -0400 (EDT)
Received: from [129.83.50.12] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 23 Apr 2012 10:41:04 -0400
Message-ID: <4F9569D5.1010306@mitre.org>
Date: Mon, 23 Apr 2012 10:40:21 -0400
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: 
References: <1537B0C1-9B8B-4D37-8D25-D863C823697D@gmx.net> <7E740085-268C-42E7-AE5C-85760D60E1B6@xmlgrrl.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040505070706070606000509"
X-Originating-IP: [129.83.31.51]
Subject: Re: [OAUTH-WG] IIW and OAuth
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, 23 Apr 2012 14:41:09 -0000

--------------040505070706070606000509
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

As I understand it, the tag of "Yukon Day" is a suggestion and doesn't 
change the unconference format, and IIW attendees are free to ignore the 
theme, just like NSTIC day last time around.

  -- Justin

On 04/23/2012 10:22 AM, John Bradley wrote:
> I was talking to Phil last week and Thursday is open IIW time like Tuesday - Wednesday.  I had thought it was a Yukon day as well, but that is apparently not happening.
>
> I think there is also a OASIS trust elevation TC thing Marry is trying to do on Thursday as well at IIW.
>
> John B.
> On 2012-04-22, at 5:50 PM, Eve Maler wrote:
>
>> I will be at IIW on Tuesday, at least part of Wednesday, and Thursday. Some UMAnitarians have suggested proposing an IIW session to collect OAuth AS/RS separation use cases. I'm happy to champion that on the Tuesday if there's interest.
>>
>> Also, we're planning to have an UMA "open meeting" during a couple of Thursday afternoon blocks, if any folks on this list would like to join in. (Thursday is "Yukon day", which is roughly the personal data ecosystem day. I can't recall how it got this moniker.)
>>
>> 	Eve
>>
>> On 16 Apr 2012, at 4:55 AM, Hannes Tschofenig wrote:
>>
>>> Hi guys,
>>>
>>> I was wondering how many of you will be at the upcoming IIW in Mountain View (or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd).
>>>
>>> I thought it might be good to useful to get together on the Friday after the IIW event for a OAuth breakfast chat.
>>> I am sure that there are still a couple of topics that require brainstorming.
>>>
>>> Drop me a message if you are able and interested.
>>>
>>> Ciao
>>> Hannes
>>>
>>> PS: Please do not forget to read the Assertion specs so that we can get them out of the door.
>>> (And thanks to those who have already read them.)
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> Eve Maler                                  http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>>
>> _______________________________________________
>> 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


--------------040505070706070606000509
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    As I understand it, the tag of "Yukon Day" is a suggestion and
    doesn't change the unconference format, and IIW attendees are free
    to ignore the theme, just like NSTIC day last time around.

    

     -- Justin

    

    On 04/23/2012 10:22 AM, John Bradley wrote:
    

      
I was talking to Phil last week and Thursday is open IIW time like Tuesday - Wednesday.  I had thought it was a Yukon day as well, but that is apparently not happening.

I think there is also a OASIS trust elevation TC thing Marry is trying to do on Thursday as well at IIW.

John B.
On 2012-04-22, at 5:50 PM, Eve Maler wrote:



      

        
I will be at IIW on Tuesday, at least part of Wednesday, and Thursday. Some UMAnitarians have suggested proposing an IIW session to collect OAuth AS/RS separation use cases. I'm happy to champion that on the Tuesday if there's interest.

Also, we're planning to have an UMA "open meeting" during a couple of Thursday afternoon blocks, if any folks on this list would like to join in. (Thursday is "Yukon day", which is roughly the personal data ecosystem day. I can't recall how it got this moniker.)

	Eve

On 16 Apr 2012, at 4:55 AM, Hannes Tschofenig wrote:



        

          
Hi guys, 

I was wondering how many of you will be at the upcoming IIW in Mountain View (or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd). 

I thought it might be good to useful to get together on the Friday after the IIW event for a OAuth breakfast chat.
I am sure that there are still a couple of topics that require brainstorming.  

Drop me a message if you are able and interested.

Ciao
Hannes

PS: Please do not forget to read the Assertion specs so that we can get them out of the door. 
(And thanks to those who have already read them.)

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


        

        

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

_______________________________________________
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


    

    

  


--------------040505070706070606000509--

From derek@ihtfp.com  Mon Apr 23 07:54:34 2012
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 DE84E21F86B6; Mon, 23 Apr 2012 07:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.668
X-Spam-Level: 
X-Spam-Status: No, score=-101.668 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gipAJlU5Nhcd; Mon, 23 Apr 2012 07:54:33 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 4D53121F86D1; Mon, 23 Apr 2012 07:54:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 45D80260299; Mon, 23 Apr 2012 10:54:28 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 29954-03; Mon, 23 Apr 2012 10:54:26 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 4158C2601D8; Mon, 23 Apr 2012 10:54:26 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3NEsNRG024957; Mon, 23 Apr 2012 10:54:23 -0400
From: Derek Atkins 
To: Michael Thomas 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>
Date: Mon, 23 Apr 2012 10:54:21 -0400
In-Reply-To: <4F917545.5080103@mtcc.com> (Michael Thomas's message of "Fri, 20 Apr 2012 07:40:05 -0700")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: 'Tim Bray' , Derek Atkins , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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, 23 Apr 2012 14:54:35 -0000

Michael Thomas  writes:

>
> Why not MUST ASN.1 while you're at it? JSON has won in case
> you'all haven't noticed it.

Well, now that you mention it...   ;-)

But seriously, we're basing this work on an RFC that was just release
six months ago and it requires XML.  Why be so quick to drop something
we just published half a year ago?  So maybe in 6 months we drop JSON
and add the next big thing?  Come on, Mike.

I agree, we should definitely support JSON.  But I also think we should
support XML.  The client can do what it wants, which is where want the
light weight implementation.

> Mike

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From derek@ihtfp.com  Mon Apr 23 08:04:41 2012
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 1C2BB21F85E4; Mon, 23 Apr 2012 08:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.988
X-Spam-Level: 
X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m146Vpmq3vXU; Mon, 23 Apr 2012 08:04:40 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7DC21F86B5; Mon, 23 Apr 2012 08:04:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 29E402602A9; Mon, 23 Apr 2012 11:04:39 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 29954-09; Mon, 23 Apr 2012 11:04:37 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 41AC7260299; Mon, 23 Apr 2012 11:04:37 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3NF4ZUF025144; Mon, 23 Apr 2012 11:04:35 -0400
From: Derek Atkins 
To: Tim Bray 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  
Date: Mon, 23 Apr 2012 11:04:34 -0400
In-Reply-To:  (Tim Bray's message of "Fri, 20 Apr 2012 08:12:13 -0700")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: Derek Atkins , oauth@ietf.org, Apps Discuss 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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, 23 Apr 2012 15:04:41 -0000

Tim Bray  writes:

> There's a disconnect here. Mnot and I (at least) have argued that
> there are very specific problems and costs associated with going
> multi-format.  I=E2=80=99ve heard lots of people say "Well, I support
> multi-format=E2=80=9D but I haven=E2=80=99t heard any specific responses =
explaining
> why those costs and problems aren=E2=80=99t real, or why the benefits are
> sufficiently great that we should just accept them.
>
> Mnot: JSON or XML: Just Decide
> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide
> tbray: Case Study: Atom and/or JSON
> http://www.tbray.org/ongoing/When/200x/2009/04/29/Model-and-Syntax#p-1
>
> Would this work better if I summarized the problems here inline in
> this thread?  It may be the pace that people=E2=80=99s IETF/email workflo=
w is
> such that they=E2=80=99re not able comfortably to consult external refere=
nces?

No, but I disagree with your conclusions.  Indeed, I disagree with your
problem statement.  Just because the server supports multiple formats
does NOT imply more work for the client.  The client can request a
specific format and never has to worry about the other, so it has NOT
doubled the work on the other side.

Let's take your rails example.  Yes, it's simple for a rails server to
output HTML, XML, JSON, and other formats.  But no, this does NOT make
it harder for the consumer of that content.  The consumer can
specifically ask for whatever format it wants!  This means you can have
a JSON-only client and it can interact 100% with your rails application
using just JSON.  It doesn't have to worry about receiving XML, because
it will always get JSON.

As for your abstract model issue..  Maybe Mike was right and we SHOULD
use ASN.1!  :-D Then we could have defined encodings to XML or JSON ;)

>  -Tim

-derek
--=20
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From mike@mtcc.com  Mon Apr 23 08:23:16 2012
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 4C8FE21F8746; Mon, 23 Apr 2012 08:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxjD55S2QQcd; Mon, 23 Apr 2012 08:23:15 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id DCD9F21F8745; Mon, 23 Apr 2012 08:23:14 -0700 (PDT)
Received: from piolinux.mtcc.com (65-172-208-69.dsl.volcano.net [65.172.208.69]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3NFN7Q6014312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 08:23:08 -0700
Message-ID: <4F9573D6.9080603@mtcc.com>
Date: Mon, 23 Apr 2012 08:23:02 -0700
From: Michael Thomas 
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Derek Atkins 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net>	<4F8852D0.4020404@cs.tcd.ie>	<9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>		<9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com>	<4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>	<091401cd1ea3$e159be70$a40d3b50$@packetizer.com>		<091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>	 <4F917545.5080103@mtcc.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1434; t=1335194589; x=1336058589; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20[apps-discuss]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Derek=20Atkins=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=55hjgRXMjNzDwpneJDH98T6BCdCvVYICzQfD1k8US7M=; b=uCncYxBwftAQRn1tgsmTzjfpEENgmnXWhTyB7GztEtN5JYqjlQhzOsAa2M o5iTU+/UXlr4m0sJwcv1gM+CF5nsKTuzxFTGqDexLXCFrzzm+QJMz4k83Xi5 VHq6tyQ87p6lmI3lDbOvYdM6Hq+6guIF2yB18i2COJYJDECA4RJ2Y=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: 'Tim Bray' , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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, 23 Apr 2012 15:23:16 -0000

Derek Atkins wrote:
> Michael Thomas  writes:
> 
>> Why not MUST ASN.1 while you're at it? JSON has won in case
>> you'all haven't noticed it.
> 
> Well, now that you mention it...   ;-)
> 
> But seriously, we're basing this work on an RFC that was just release
> six months ago and it requires XML.  Why be so quick to drop something
> we just published half a year ago?  So maybe in 6 months we drop JSON
> and add the next big thing?  Come on, Mike.
> 
> I agree, we should definitely support JSON.  But I also think we should
> support XML.  The client can do what it wants, which is where want the
> light weight implementation.

I think you're probably misunderstanding me. I'm (I believe) with Tim
in saying "pick one". Just one. For clients and servers. And I'm only
saying that JSON is preferable because it has pretty much taken
over -- I see JSON all the time with webbish ajax-y data stuff and XML
almost never unless it's something vaguely markup-like. JSON is clean
in a what you see is what you get kind of way, and I'm puzzled by people
calling a 6 year old RFC a "flavor of the day" -- c'mon.

 From a programming standpoint, JSON is just easier to deal with. Consider
these two links:

http://php.net/manual/en/book.json.php

http://php.net/manual/en/book.xml.php

and tell me which you'd rather deal with. It's not huge, but it's not
nothing either.

Mike

Mike

From jricher@mitre.org  Mon Apr 23 08:23:23 2012
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 3565621F874C for ; Mon, 23 Apr 2012 08:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.546
X-Spam-Level: 
X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDUR+I23QTIU for ; Mon, 23 Apr 2012 08:23:21 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1D62621F8749 for ; Mon, 23 Apr 2012 08:23:21 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9CBA421B1511 for ; Mon, 23 Apr 2012 11:23:20 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8C87121B150D for ; Mon, 23 Apr 2012 11:23:20 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0283.003; Mon, 23 Apr 2012 11:23:20 -0400
From: "Richer, Justin P." 
To: "oauth@ietf.org WG" 
Thread-Topic: New Version Notification for draft-richer-oauth-xml-01.txt
Thread-Index: AQHNIWS22qb5DHapLEi/mGe/m647iQ==
Date: Mon, 23 Apr 2012 15:23:19 +0000
Message-ID: 
References: <20120423152104.13855.72662.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [129.83.50.26]
Content-Type: multipart/alternative; boundary="_000_CDD7E1A6C6E44803A436B6D3DCA43352mitreorg_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-xml-01.txt
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, 23 Apr 2012 15:23:23 -0000

--_000_CDD7E1A6C6E44803A436B6D3DCA43352mitreorg_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

New revision of the Alternate Encodings draft is now posted to the IETF dat=
a tracker.

http://tools.ietf.org/html/draft-richer-oauth-xml-01

 -- Justin

Begin forwarded message:

From: >
Subject: New Version Notification for draft-richer-oauth-xml-01.txt
Date: April 23, 2012 11:21:04 AM EDT
To: >

A new version of I-D, draft-richer-oauth-xml-01.txt has been successfully s=
ubmitted by Justin Richer and posted to the IETF repository.

Filename: draft-richer-oauth-xml
Revision: 01
Title: Alternate Encoding for OAuth 2 Token Responses
Creation date: 2012-04-23
WG ID: Individual Submission
Number of pages: 12

Abstract:
  This document describes a method of representing the JSON structured
  responses from the OAuth 2 Token Endpoint into XML and form encoded
  responses.





The IETF Secretariat


--_000_CDD7E1A6C6E44803A436B6D3DCA43352mitreorg_
Content-Type: text/html; charset="us-ascii"
Content-ID: <608FE76E7CB3FF4E889E07989FA016E8@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable






New revision of the Alternate Encodings draft is now posted to the IETF dat=
a tracker.












 -- Justin





Begin forwarded message:







From:
<<=
a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=






Subject:
Ne=
w Version Notification for draft-richer-oauth-xml-01.txt





Date:
April=
 23, 2012 11:21:04 AM EDT





To:
<<=
a href=3D"mailto:jricher@mitre.org">jricher@mitre.org>






A new version of I-D, draft-richer-oauth-xml-01.txt has been successfu=
lly submitted by Justin Richer and posted to the IETF repository.



Filename: d=
raft-richer-oauth-xml

Revision: 0=
1

Title: Alternate Encod=
ing for OAuth 2 Token Responses

Creation date: 2012-04-23

WG ID: Individual Subm=
ission

Number of pages: 12



Abstract:

  This document describes a method of representing the JSON struc=
tured

  responses from the OAuth 2 Token Endpoint into XML and form enc=
oded

  responses.











The IETF Secretariat














--_000_CDD7E1A6C6E44803A436B6D3DCA43352mitreorg_--

From duck@kronkltd.net  Fri Apr 20 08:09:00 2012
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 EC8A321F8790 for ; Fri, 20 Apr 2012 08:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8xmTmcWzmtY for ; Fri, 20 Apr 2012 08:08:58 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF8321F8778 for ; Fri, 20 Apr 2012 08:08:57 -0700 (PDT)
Received: by lagj5 with SMTP id j5so8127013lag.31 for ; Fri, 20 Apr 2012 08:08:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kronkltd.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ESOI79YE9OcmZleClSG7tO/QB7+Eko5Q06rZuqjLiZM=; b=JBGu2HEDxkeH3XJvz/2Q3FitMobgo7x6opbGhyJbnyq22j440wZN8loT7du3YVi0C9 VGpuB8Tlyn6w4Cd3VyfZ1Y6lLNgiptJhGClSTmwW6XCQqfa8hDPuOa/iCoSg3n7Elp4E qkaqfqca+w038/tjhmXVga1bdPQGDefWTL/BQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ESOI79YE9OcmZleClSG7tO/QB7+Eko5Q06rZuqjLiZM=; b=bFQvZOc/ApyuZ0xpYZqqaoj95PhXKx4dnzmXvIA9yCNJkS5lmo5p3P+whjhHeIUXXQ r4L6lcRKsbrqvqU2QYD0Wh/El6rVI0PUfm26uU8eOL0U9MLy/3Ir00KXpB0LLS5Axc7f ASkfhlKQG69gxSVQqmyo4WnqdBBeQqEbfZJdjLks+RIZ1a60++fmTOqSDJ5yXVGZYVQn GEPj8powlvAdArsn9SsA6G+OodhZko9uc5jehmVYpKYb3MW00+YnWzDE381QIr+XVb3A V83Xkxl0tG88KotCmFij5zLvA2maV1Ao5hvU71pY287+cbUJCor50J4knjvEEi6bVsxm /WVQ==
Received: by 10.152.145.135 with SMTP id su7mr3903416lab.5.1334934536710; Fri, 20 Apr 2012 08:08:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.128.41 with HTTP; Fri, 20 Apr 2012 08:08:34 -0700 (PDT)
In-Reply-To: <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664915EF@TK5EX14MBXC284.redmond.corp.microsoft.com> <091d01cd1eb7$da2c7ed0$8e857c70$@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664916A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <1334933123.53510.YahooMailNeo@web31803.mail.mud.yahoo.com>
From: Daniel Renfer 
Date: Fri, 20 Apr 2012 11:08:34 -0400
Message-ID: 
To: William Mills 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmzwXXxpERDl8lz09VyO0Qtn59lXmVqu6sol5M+xOzedgIVO7HBcq74rVzunScxE1eQqvBV
X-Mailman-Approved-At: Mon, 23 Apr 2012 08:24:21 -0700
Cc: "oauth@ietf.org" , Apps Discuss 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Fri, 20 Apr 2012 15:09:00 -0000

The point is that existing WF clients have been written to not use the
resource parameter because in the past, that parameter hasn't been
available or hasn't been reliable.

If the resource parameter is required, this older method of fetching
the host meta and constructing the url to fetch the user meta would
still continue to work just as before.

Even if the resource parameter were made mandatory today, real world
WF clients would still have to account for the possibility of resource
queries resulting in an error or incorrect information. Given the
number of currently deployed WF-enabled services and the difficulty in
upgrading all of them, this is going to be the case for some time.

resource parameters should be strongly encouraged, but not required.

On Fri, Apr 20, 2012 at 10:45 AM, William Mills  wrot=
e:
> So you are guaranteeing that there are no clients using WF today?
>
> ________________________________
> From: Mike Jones 
> To: Paul E. Jones ; 'Murray S. Kucherawy'
> ; "oauth@ietf.org" ; 'Apps Discuss'
> 
> Sent: Thursday, April 19, 2012 10:48 PM
> Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discover=
y
> (SWD)
>
> To be clear, making this mandatory would break no clients.=C2=A0 It would=
 require
> updating some servers, just as requiring JSON would.=C2=A0 This seems lik=
e a fair
> tradeoff when it makes an appreciable difference in user interface latenc=
y
> in some important scenarios.=C2=A0 If you and the other key WebFinger sup=
porters
> can agree to making "resource" support mandatory and requiring JSON, I
> believe we may have a path forward.
>
> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 Cheers,
> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 -- Mike
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Thursday, April 19, 2012 10:39 PM
> To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'
> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discover=
y
> (SWD)
>
> That's correct.=C2=A0 We could certainly make it mandatory, but the reaso=
n it
> isn't is to maintain backward compatibility with existing deployments.
>
> I think we should always think carefully when we decide to make a change
> that breaks backward-compatibility.=C2=A0 This is one change that would d=
o that.
>
> Paul
>
>> -----Original Message-----
>> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
>> Sent: Friday, April 20, 2012 1:10 AM
>> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'
>> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
>> Discovery
>> (SWD)
>>
>> Currently, support for the "resource" parameter is optional, as per
>> the following (correct?):
>>
>>=C2=A0 =C2=A0 Note that support for the "resource" parameter is optional,=
 but
>>=C2=A0 =C2=A0 strongly RECOMMENDED for improved performance.=C2=A0 If a s=
erver does not
>>=C2=A0 =C2=A0 implement the "resource" parameter, then the server's host =
metadata
>>=C2=A0 =C2=A0 processing logic remains unchanged from RFC 6415.
>>
>> To truly support 1, this would need to be changed to REQUIRED, correct?
>>
>> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 -- Mike
>>
>> -----Original Message-----
>> From: Paul E. Jones [mailto:paulej@packetizer.com]
>> Sent: Thursday, April 19, 2012 8:16 PM
>> To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'
>> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
>> Discovery
>> (SWD)
>>
>> Mike,
>>
>> > There are two criteria that I would consider to be essential
>> > requirements for any resulting general-purpose discovery specification=
:
>> >
>> > 1.=C2=A0 Being able to always discover per-user information with a sin=
gle
>> > GET (minimizing user interface latency for mobile devices, etc.)
>>
>> WF can do that.=C2=A0 See:
>> $ curl -v https://packetizer.com/.well-known/\
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 host-meta.json?resource=3Dacct:paulej@=
packetizer.com
>>
>> > 2.=C2=A0 JSON should be required and it should be the only format
>> > required (simplicity and ease of deployment/adoption)
>>
>> See the above example.=C2=A0 However, I also support XML with my server.
>> It took me less than 10 minutes to code up both XML and JSON
>> representations.
>> Once the requested format is determined, the requested URI is
>> determined, data is pulled from the database, spitting out the desired
>> format is trivial.
>>
>> Note, and very important note: supporting both XML and JSON would only
>> be a server-side requirement.=C2=A0 The client is at liberty to use the
>> format it prefers.=C2=A0 I would agree that forcing a client to support
>> both would be unacceptable, but the server?=C2=A0 Nothing to it.
>>
>> > SWD already meets those requirements.=C2=A0 If the resulting spec meet=
s
>> > those requirements, it doesn't matter a lot whether we call it
>> > WebFinger or Simple Web Discovery, but I believe that the
>> > requirements discussion is probably the most productive one to be
>> > having at this point - not the starting point document.
>>
>> I believe WebFinger meets those requirements.=C2=A0 We could debate whet=
her
>> XML should be supported, but I'll note (again) that it is there in RFC
>> 6415.
>> That document isn't all that old and, frankly, it concerns me that we
>> would have a strong preference for format A one week and then Format B
>> the next.
>> We are where we are and I can see reason for asking for JSON, but no
>> good reason to say we should not allow XML (on the server side).
>>
>> Paul
>>
>>
>>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From Michael.Jones@microsoft.com  Sat Apr 21 09:37:51 2012
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 B472A21F861A for ; Sat, 21 Apr 2012 09:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.337
X-Spam-Level: 
X-Spam-Status: No, score=-5.337 tagged_above=-999 required=5 tests=[AWL=1.262,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oK7T2VXVUJc for ; Sat, 21 Apr 2012 09:37:46 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2D67E21F85D2 for ; Sat, 21 Apr 2012 09:37:46 -0700 (PDT)
Received: from mail75-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Sat, 21 Apr 2012 16:37:45 +0000
Received: from mail75-tx2 (localhost [127.0.0.1])	by mail75-tx2-R.bigfish.com (Postfix) with ESMTP id 4F3ADE0440	for ; Sat, 21 Apr 2012 16:37:45 +0000 (UTC)
X-SpamScore: -36
X-BigFish: VS-36(zzbb2dI9371I542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail75-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail75-tx2 (localhost.localdomain [127.0.0.1]) by mail75-tx2 (MessageSwitch) id 1335026263489781_21054; Sat, 21 Apr 2012 16:37:43 +0000 (UTC)
Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.242])	by mail75-tx2.bigfish.com (Postfix) with ESMTP id 692594A0248	for ; Sat, 21 Apr 2012 16:37:43 +0000 (UTC)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 21 Apr 2012 16:37:42 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0283.004; Sat, 21 Apr 2012 16:37:41 +0000
From: Mike Jones 
To: "Paul E. Jones" , 'Michael Thomas' ,  'Derek Atkins' 
Thread-Topic: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
Thread-Index: AQHNH3TGzG4/4A/7x0C5JawAKFEmIJald/WQ
Date: Sat, 21 Apr 2012 16:37:40 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943664920DE@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917CE6.2060904@mtcc.com> <0a7601cd1f74$cc5a26a0$650e73e0$@packetizer.com>
In-Reply-To: <0a7601cd1f74$cc5a26a0$650e73e0$@packetizer.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-Mailman-Approved-At: Mon, 23 Apr 2012 08:24:21 -0700
Cc: 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery	(SWD)
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: Sat, 21 Apr 2012 16:37:51 -0000

I want to completely agree with what Paul wrote: "What is a pain on the cli=
ent side is conditional code that has to be followed in order to consume wh=
atever the server wants to send.  The client should have a single code path=
 knowing it will get what it wants".

BTW, this is also part of the argument for making the resource parameter re=
quired.  Paul's example of:
	curl -v https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:=
paulej@packetizer.com
should work on all deployments - not just packetizer.com, so clients can re=
ly on it working (and not have to have conditional code to try again in a d=
ifferent way when it doesn't).

As a design principle, to the extent there's any complexity, it should be p=
ushed to the servers, rather than the clients, as clients will vastly outnu=
mber servers.    The solution should be as simple for clients to use as pos=
sible, to facilitate adoption.

				Best wishes,
				-- Mike

(moved OAuth to bcc)	=09

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] =
On Behalf Of Paul E. Jones
Sent: Friday, April 20, 2012 9:11 PM
To: 'Michael Thomas'; 'Derek Atkins'
Cc: oauth@ietf.org; 'Apps Discuss'
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery =
(SWD)

Mike,

> On 04/20/2012 07:17 AM, Derek Atkins wrote:
> >  Note that this is a replay of the historical "MUST=20
> > Implement" versus "MUST Use" arguments. Just because the server MUST=20
> > IMPLEMENT JSON and XML does not mean that a Client must use both (or=20
> > even that a client must implement both). It is perfectly reasonable=20
> > and generally acceptable to have a server that provides data in=20
> > multiple formats whereas the client only supports a subset and=20
> > specifies which format(s) are acceptable.  -derek
>=20
> To Paul's point about how easy it is for a server to support both, I'd=20
> retort that it's equally easy for a client to gin up JSON instead of XML.

I don't follow.

I agree I could write a client that could do JSON easily.
I agree I could write a client that could do XML easily.

What is a pain on the client side is conditional code that has to be follow=
ed in order to consume whatever the server wants to send.  The client shoul=
d have a single code path knowing it will get what it wants, ether XML or J=
SON.

Granted, the server has to have a conditional statement and generate XML or=
 JSON as requested.  However, generating either is trivial.  Really, I did =
it in minutes.  We're not talking about huge complex data structures here w=
ith WebFinger.

> Pity the poor programmer who can't get their head around that gigantic=20
> change. On the other hand, having to support XML and JSON is an=20
> ongoing maintenance headache server-side. Why do it?

Would we expect to see a lot of changes to the data structures used by WebF=
inger?  That's really the only ongoing maintenance issue.  Don't touch the =
code that produces the XML or JSON and there is no ongoing maintenance.

> There isn't even the dubious
> religious war like back in the day saying that binary encoded ASN.1=20
> was "better/faster/stacks and cleans dishes" than "human readable"=20
> XML.  XML is just a clunky and past its prime text encoding at this=20
> point. Requiring it smacks of nostalgia to me.

I disagree with you on that one.  First, ASN.1 is better for defining proto=
cols, so long as you stay away from the complex stuff. Basic ASN.1 looks a =
lot like C and produces C data structures that can be readily read, decoded=
, and consumed in C code.  Rarely, rarely do I see decoding issues when usi=
ng ASN.1, whereas issues pop up quite often with text protocols, especially=
 things like SIP where a semi-colon in the wrong place breaks things.  But,=
 let's not start that debate again ;-)

XML *can* be big and clunky.  As you've well noticed, I can also write leng=
thy emails that seem to have more typos as the evening progresses. :-)

However, XML can be a very compact encoding and it's extremely readable.

I just did a query on my server to see the XML vs. JSON output.  The XRD do=
cument provided was 1032 octets.  The JRD document was 1077 octets.
Removing every possible space and making both formats hard as heck to read,=
 JSON was 837 and XML was 940.  I'm hard pressed to say that's makes much d=
ifference.  Further, I can't read either of them now without some effort.

Considering that a lot of WebFinger use (I suspect) is going to be server-t=
o-server interaction, XML seems like a reasonable format to retain.
That, and the fact it is already mandatory in RFC 6415 and deployed out the=
re.

It's not nostalgia for me.  XML is a very well-structured, readable format.
No objection to JSON, but I really don't understand the clamoring for JSON.
I guess more precisely, I don't understand the disdain for XML.  Is it beca=
use people created hideously complex XML data structures and feel pain for =
having done that?  XRD is not that kind of document.

Paul


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



From bobwyman@gmail.com  Sat Apr 21 10:15:00 2012
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 0A0C821F861A; Sat, 21 Apr 2012 10:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.326
X-Spam-Level: 
X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx3xU8hYln08; Sat, 21 Apr 2012 10:14:55 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4B921F8613; Sat, 21 Apr 2012 10:14:55 -0700 (PDT)
Received: by qaea16 with SMTP id a16so899495qae.10 for ; Sat, 21 Apr 2012 10:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ad8gYKZ/ySi/hvXpf/ubn/oz+o9tqn0KEZsS2oXxLjs=; b=Z+Ad3AgOeZHHvbi8nUmr6863BSyTbRRlChBhggIFVnArXLamH29a2rkW/9HT2IPy2d 3NkE+dY1Yhzx8k/Rr7O2dKPWXw1q0ivOGqY8eJLZ28YYBenHCqDpeFaVc9E98oSxKtnV RqV6NafwKTNpt56RJOrV/x4O8LTwxRTJpj6UMmiN0k8E9Y7GxdsCkvyQxIXDVjidXBYd cPhDwwPlAHerH+5mE7j9DmBw/06hrfaWUM3tGxu6aaspyz95ZKqyREbCrFk9cBoMwkKr z2c/ymiO4IMO7yz1S6BJzg1nHkhXawNg8YnIqzpLDS/DvOTxdDB7P4UaD2w0S0bZFcq1 GjaA==
MIME-Version: 1.0
Received: by 10.229.105.224 with SMTP id u32mr2982622qco.41.1335028494815; Sat, 21 Apr 2012 10:14:54 -0700 (PDT)
Sender: bobwyman@gmail.com
Received: by 10.229.12.194 with HTTP; Sat, 21 Apr 2012 10:14:53 -0700 (PDT)
In-Reply-To: <4F921E53.8030109@cs.tcd.ie>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com> <4F921E53.8030109@cs.tcd.ie>
Date: Sat, 21 Apr 2012 13:14:53 -0400
X-Google-Sender-Auth: 9GJRFmrFiGds-WiqpEn_f2wKcYY
Message-ID: 
From: Bob Wyman 
To: Stephen Farrell 
Content-Type: multipart/alternative; boundary=00235429cd4032d2f804be338bec
X-Mailman-Approved-At: Mon, 23 Apr 2012 08:24:21 -0700
Cc: Derek Atkins , oauth@ietf.org, Apps Discuss 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Sat, 21 Apr 2012 17:15:00 -0000

--00235429cd4032d2f804be338bec
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 20, 2012 at 10:41 PM, Stephen Farrell  wrote:

>
>
> On 04/20/2012 03:40 PM, Michael Thomas wrote:
> >
> > Why not MUST ASN.1 while you're at it? JSON has won in case
> > you'all haven't noticed it.
>
> Well, I also remember when XML won over ASN.1, or
> was that some RPC thing?

Of course, long before "XML won over ASN.1" ASN.1 won over XML's
predecessor; SGML. Back in the early to mid-80's, when we were defining the
ISO X.4xx and X.5xx standards, the IBM and Unix crowds were pushing SGML as
the alternative to the binary encodings of ASN.1. But, Digital and the
Telcos pushed for the binary encodings and won.

These days, XML is just another encoding for ASN.1 since ASN.1 finally
defined the XML Encoding Rules
(XER)a few years back.

If we had agreed on ASN.1 years ago, we wouldn't be having these encoding
format debates every few years. ASN.1 is an "Abstract Syntax Notation" that
can be mapped to a large number of encoding rules. If we were using ASN.1,
what we would do is define the "schema" or syntax for data abstractly and
then specify the actual encoding as a secondary issue. Given that one
encoding can be translated to another, implementations would be free to use
whatever encoding was most convenient or appropriate for them. But, that
would be a different universe than the one we live in today.

Seems like a new format wins
> about every five years or so, once the last winner
> gets enough crap added. (JSON pointer seems like the
> start of a nice slippery slope to me.)
>
> I've no opinion as to what should be MTI here however,
> just a side comment.
>
> S
>
> >
> > Mike
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--00235429cd4032d2f804be338bec
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Fri, Apr 20, 2012 at 10:41 PM, Stephe=
n Farrell <stephen.farrell@cs.tcd.ie> wrote:






On 04/20/2012 03:40 PM, Michael Thomas wrote:

>

> Why not MUST ASN.1 while you're at it? JSON has won in case

> you'all haven't noticed it.




Well, I also remember when XML won over ASN.1, or

was that some RPC thing?
Of course, long before "XML =
won over ASN.1" ASN.1 won over XML's predecessor; SGML. Back in th=
e early to mid-80's, when we were defining the ISO X.4xx and X.5xx stan=
dards, the IBM and Unix crowds were pushing SGML as the alternative to the =
binary encodings of ASN.1. But, Digital and the Telcos pushed for the binar=
y encodings and won.



These days, XML is just another encoding for ASN.1 sinc=
e ASN.1 finally defined the XML Encoding Rules (XER) a few years back.=A0



If we had agreed on ASN.1 years ago, we wouldn't be having these e=
ncoding format debates every few years. ASN.1 is an "Abstract Syntax N=
otation" that can be mapped to a large number of encoding rules. If we=
 were using ASN.1, what we would do is define the "schema" or syn=
tax for data abstractly and then specify the actual encoding as a secondary=
 issue. Given that one encoding can be translated to another, implementatio=
ns would be free to use whatever encoding was most convenient or appropriat=
e for them. But, that would be a different universe than the one we live in=
 today.



Seems like a new format wins<=
br>
about every five years or so, once the last winner

gets enough crap added. (JSON pointer seems like the

start of a nice slippery slope to me.)



I've no opinion as to what should be MTI here however,

just a side comment.




S



>

> Mike

> _______________________________________________

> apps-discuss mailing list

> apps-discuss@ietf.org

> https://www.ietf.org/mailman/listinfo/apps-discuss

>

_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





--00235429cd4032d2f804be338bec--

From duerst@it.aoyama.ac.jp  Mon Apr 23 00:15:35 2012
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 DFA5A21F859F for ; Mon, 23 Apr 2012 00:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.076
X-Spam-Level: 
X-Spam-Status: No, score=-98.076 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27mJrbwubipR for ; Mon, 23 Apr 2012 00:15:35 -0700 (PDT)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2E59221F8568 for ; Mon, 23 Apr 2012 00:15:35 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q3N7FQCt011283 for ; Mon, 23 Apr 2012 16:15:26 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 09ea_bce8_197ae8e0_8d14_11e1_ade9_001d096c5782; Mon, 23 Apr 2012 16:15:25 +0900
Received: from [IPv6:::1] ([133.2.210.1]:38331) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Mon, 23 Apr 2012 16:15:25 +0900
Message-ID: <4F95018C.4010806@it.aoyama.ac.jp>
Date: Mon, 23 Apr 2012 16:15:24 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Stephen Farrell 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net>	<4F8852D0.4020404@cs.tcd.ie>	<9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>		<9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com>	<4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>	<091401cd1ea3$e159be70$a40d3b50$@packetizer.com>		<091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>	 <4F917545.5080103@mtcc.com> <4F921E53.8030109@cs.tcd.ie>
In-Reply-To: <4F921E53.8030109@cs.tcd.ie>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 23 Apr 2012 08:24:21 -0700
Cc: Derek Atkins , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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, 23 Apr 2012 07:15:36 -0000

On 2012/04/21 11:41, Stephen Farrell wrote:

> On 04/20/2012 03:40 PM, Michael Thomas wrote:
>>
>> Why not MUST ASN.1 while you're at it? JSON has won in case
>> you'all haven't noticed it.
>
> Well, I also remember when XML won over ASN.1, or
> was that some RPC thing? Seems like a new format wins
> about every five years or so, once the last winner
> gets enough crap added. (JSON pointer seems like the
> start of a nice slippery slope to me.)

There's a bit of that indeed. However, as others have noted, JSON is 
indeed better suited for exchanging *data* between programs, in 
particular between scripting languages, because their main datatypes are 
numbers and strings, and their main data structures are arrays and 
hashes (or whatever they are called).

In contrast to that, XML originated as a document format. It's way 
better than JSON for documents, and for mixed document/data situations, 
but if all you do is exchanging data (structures) between programs, JSON 
wins.

Regards,   Martin.

From mike@mtcc.com  Mon Apr 23 08:41:07 2012
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 948A221F84E6; Mon, 23 Apr 2012 08:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAaA7eEgRw2Q; Mon, 23 Apr 2012 08:41:06 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id D9E5C21F84DF; Mon, 23 Apr 2012 08:41:06 -0700 (PDT)
Received: from piolinux.mtcc.com (65-172-208-69.dsl.volcano.net [65.172.208.69]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3NFf0dF020368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 08:41:01 -0700
Message-ID: <4F957807.3090409@mtcc.com>
Date: Mon, 23 Apr 2012 08:40:55 -0700
From: Michael Thomas 
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Stephen Farrell 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com> <4F921E53.8030109@cs.tcd.ie>
In-Reply-To: <4F921E53.8030109@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=928; t=1335195662; x=1336059662; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[apps-discuss]=20[OAUTH-WG]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Stephen=20Farrell=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=o+xM5OZGu5C47gYVnWyfPXPbvUVDBkKnYvhCaIMAqHY=; b=sIpnE4I0pC7HMb9hKDh/aoWdNgqSwMSHdY2Ylas+5Qn+vlunn6vcWOtyWl L5lNRzZZ5cSnDxrEbrfjZUTBQgLGTR0SixYXlEwFvmr72mHJuag2mI709IPP U5Toozl8kYpG8tqEqckjl9AlbMGmYGQSSRZp145Uk84wObnCRFWUc=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: Derek Atkins , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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, 23 Apr 2012 15:41:07 -0000

Stephen Farrell wrote:
> 
> On 04/20/2012 03:40 PM, Michael Thomas wrote:
>> Why not MUST ASN.1 while you're at it? JSON has won in case
>> you'all haven't noticed it.
> 
> Well, I also remember when XML won over ASN.1, or
> was that some RPC thing? Seems like a new format wins
> about every five years or so, once the last winner
> gets enough crap added. (JSON pointer seems like the
> start of a nice slippery slope to me.)
> 
> I've no opinion as to what should be MTI here however,
> just a side comment.
> 

As a producer of schemas for my own purposes, I always feel like I'm
likely doing something wrong when I hack up XML, and I'm most likely
right since I haven't -- and don't want to -- read half of the RFC's.
Not so with JSON. I read 4627 through and thought -- groovy, nothing
more than meets the eye! It's impossible to sin!

Mike, and yes JSON will turn to crap if it gets loved to death

From mike@mtcc.com  Mon Apr 23 09:09:21 2012
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 117B421F864A for ; Mon, 23 Apr 2012 09:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWwafvVWNi9f for ; Mon, 23 Apr 2012 09:09:20 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id E775121F858B for ; Mon, 23 Apr 2012 09:09:19 -0700 (PDT)
Received: from piolinux.mtcc.com (65-172-208-69.dsl.volcano.net [65.172.208.69]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3NG9FQn030053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 09:09:16 -0700
Message-ID: <4F957EA7.3060004@mtcc.com>
Date: Mon, 23 Apr 2012 09:09:11 -0700
From: Michael Thomas 
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Barry Leiba , "oauth@ietf.org" 
References: 	<4F8DE789.4030704@mtcc.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1181; t=1335197357; x=1336061357; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20Shepherd=20review=20of=20draft-ietf-oau th-v2-threatmodel |Sender:=20 |To:=20Barry=20Leiba=20,=20=0A=20= 22oauth@ietf.org=22=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=fy930Q+o/eN1HuLqTe+RCddhD240XjHzAjwWuT4CwrI=; b=BMXZKV9RC1KR9/pIKuhqT5RNgDh1akOncFmj2F7TgVQ1DYVPzNN9Oe/PPa +wrfQbBXLSJ459MOpREgmkJhoTBei3ya4aRpTElzmDBbugl74c2ZozOn6Ep3 LXqzsiia2GCEB94UurZkqOJA4GOXZZNeDK1lL4hFhQYlsdrB3OVhE=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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, 23 Apr 2012 16:09:21 -0000

[I accidentally sent just to Barry my take on his addition which I think is fine
except for one thing addition...]

Barry Leiba wrote:
> You sent it just to me.  I think it's a reasonable addition, so please
> send it to the distribution (which at the moment does not include the
> OAuth list, just the
>  alias), and
> suggest specific text to add.  I presume it would go in an new bullet
> just before the last.

The thing I think is missing here is that the Authorization Server has a
stake in mitigating threats, and actually has a quite potent one: it can
be selective with whom it enrolls, and can revoke bad actors.

So let me try a bullet:

o While end users are mostly incapable of properly vetting applications they
   load onto their devices, those who deploy Authorization Servers have tools at
   their disposal to mitigate malicious Clients. Namely, in order to become a threat
   at all, a Client must first become a Client. A well run Authorization Server MAY
   require a curation process when enrolling Clients, and SHOULD have processes to
   revoke bad actors after enrollment.

Mike

From derek@ihtfp.com  Mon Apr 23 09:55:51 2012
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 369EB21F867F; Mon, 23 Apr 2012 09:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.637
X-Spam-Level: 
X-Spam-Status: No, score=-101.637 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TICFkOByLTh; Mon, 23 Apr 2012 09:55:50 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB0A21F866D; Mon, 23 Apr 2012 09:55:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D1513260299; Mon, 23 Apr 2012 12:55:49 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 30604-10; Mon, 23 Apr 2012 12:55:48 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id BD8B52601D8; Mon, 23 Apr 2012 12:55:48 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3NGtfvk027083; Mon, 23 Apr 2012 12:55:41 -0400
From: Derek Atkins 
To: Michael Thomas 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>  <4F9573D6.9080603@mtcc.com>
Date: Mon, 23 Apr 2012 12:55:40 -0400
In-Reply-To: <4F9573D6.9080603@mtcc.com> (Michael Thomas's message of "Mon, 23 Apr 2012 08:23:02 -0700")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: 'Tim Bray' , Derek Atkins , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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, 23 Apr 2012 16:55:51 -0000

Michael Thomas  writes:

> Derek Atkins wrote:
>> Michael Thomas  writes:
>>
>>> Why not MUST ASN.1 while you're at it? JSON has won in case
>>> you'all haven't noticed it.
>>
>> Well, now that you mention it...   ;-)
>>
>> But seriously, we're basing this work on an RFC that was just release
>> six months ago and it requires XML.  Why be so quick to drop something
>> we just published half a year ago?  So maybe in 6 months we drop JSON
>> and add the next big thing?  Come on, Mike.
>>
>> I agree, we should definitely support JSON.  But I also think we should
>> support XML.  The client can do what it wants, which is where want the
>> light weight implementation.
>
> I think you're probably misunderstanding me. I'm (I believe) with Tim
> in saying "pick one". Just one. For clients and servers. And I'm only

No, I'm not misunderstanding you, I know exactly what you are arguing
for.  And I'm agreeing with you that we must support JSON.  However, I
disagree that we should drop XML, especially considering 6415 requires
XML and it was just released 6 months ago.

I'm also saying that this is only a server-side requirement to support
both.  The client can choose to support only one based on its own
requirements.  If you already have an XML-based client, why force them
to add JSON support?  Similarly, if you already have a JSON-based
client, why force them to add XML support?

If you're writing a client, you can ignore XML and only play with JSON.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From bcampbell@pingidentity.com  Mon Apr 23 10:52:09 2012
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 272E821F84EB for ; Mon, 23 Apr 2012 10:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.934
X-Spam-Level: 
X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcWzkwMjZlpS for ; Mon, 23 Apr 2012 10:52:08 -0700 (PDT)
Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4846F21F8532 for ; Mon, 23 Apr 2012 10:52:07 -0700 (PDT)
Received: from mail-vb0-f53.google.com ([209.85.212.53]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKT5WWxiBUPz0j0Y2yZpOPp3tgHWuckruC@postini.com; Mon, 23 Apr 2012 10:52:07 PDT
Received: by vbbfc26 with SMTP id fc26so10073138vbb.40 for ; Mon, 23 Apr 2012 10:52:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=N5CmHXXuCZRdabxIMtBO7A1Q3eeDd4RAW+LbDKCZXUY=; b=IHf9uLEt1EhWZ3ZTMwHbVViyg5MZI8y9kpbdQNcQabssF2zX2e6gElXZg4xWcjlvND SW1M6q3Lcht0R/c7L92IoGmtVrh1Ex9k722zOtj0INQZRggy/8sDCFJJ4MoS8IaX3O9C qbHrKVuZxbK9zuVIYAvv0dPEMrdN1+zzxC9tUHoSaR7TkwzLoWyBXlifKe5k+rwcuUaw FiKCgDJkwLd10uGxYrjF6QZP1hJRUzG6bgtujK5rCZO2vxRB0DtUz3havX9j58maWwAm J17QPzTfprB+c14DljXMutSoXctdQ28xCe8BbNqu2Gze+hxQDw/KGvzmTdze9YwGbqyK oJbA==
Received: by 10.52.65.170 with SMTP id y10mr164613vds.48.1335203525851; Mon, 23 Apr 2012 10:52:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.38.104 with HTTP; Mon, 23 Apr 2012 10:51:35 -0700 (PDT)
From: Brian Campbell 
Date: Mon, 23 Apr 2012 11:51:35 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=20cf307f3af2dc7b8304be5c4bcf
X-Gm-Message-State: ALoCoQnyhOl80k99k4uvmh8QLvPefk7ztr5oqXdfCNoraZbNIx9HSA6hgAx0e1emm4YfIj6/qg95
Subject: [OAUTH-WG] draft-ietf-oauth-assertions WGLC comment IV
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, 23 Apr 2012 17:52:09 -0000

--20cf307f3af2dc7b8304be5c4bcf
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=A74.2* discusses the use of the scope parameter in an authorization grant
request.  This section should probably reference =A73.3 of
draft-ietf-oauth-v2** for the formal definition of scope and, subsequently,
a fair amount of text can be removed from the assertions draft.


* http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.2
** http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-3.3

--20cf307f3af2dc7b8304be5c4bcf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=A74.2* discusses the use of the scope parameter in an authorization grant =
request.=A0 This section should probably reference =A73.3 of draft-ietf-oau=
th-v2** for the formal definition of scope and, subsequently, a fair amount=
 of text can be removed from the assertions draft. 




* http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#=
section-4.2
** http://tools.ietf.org/html/draft-ietf-oauth-v2-25#sect=
ion-3.3






--20cf307f3af2dc7b8304be5c4bcf--

From eran@hueniverse.com  Mon Apr 23 14:19:32 2012
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 8FB5521F8599 for ; Mon, 23 Apr 2012 14:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Level: 
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rf2WkpJRavmF for ; Mon, 23 Apr 2012 14:19:31 -0700 (PDT)
Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id 869C321F8598 for ; Mon, 23 Apr 2012 14:19:31 -0700 (PDT)
Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id 1ZKX1j0020CJzpC01ZKXSF; Mon, 23 Apr 2012 14:19:31 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 14:19:31 -0700
From: Eran Hammer 
To: "oauth@ietf.org WG (oauth@ietf.org)" 
Thread-Topic: OAuth ABNF
Thread-Index: Ac0hlo/WWuxsG+HsR9eTWVbGALjxfA==
Date: Mon, 23 Apr 2012 21:19:30 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFB23D@P3PWEX2MB008.ex2.secureserver.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FFB23DP3PWEX2MB008ex2se_"
MIME-Version: 1.0
Subject: [OAUTH-WG] OAuth ABNF
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, 23 Apr 2012 21:19:32 -0000

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FFB23DP3PWEX2MB008ex2se_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

During the IESG review of draft-ietf-oauth-v2, Sean Turner raised the follo=
wing DISCUSS item (meaning, the specification is blocked until this is reso=
lved):



> 0) General: I found the lack of ABNF somewhat disconcerting in that

> implementers would have to hunt through the spec to figure out all the

> values of a given field.  For example grant_type has different values bas=
ed

> on the different kind of access_token requests - four to be more precise =
-

> but there's no ABNF for the field.  There are many examples of

> this.   It would greatly aid implementers if a) the ABNF for all fields

> were included in the draft and b) all the ABNF was collected in one place=
.  I

> had individual discusses for each field that had missing ABNF, but it was

> getting out of hand so I'm just going to do this one general discuss on t=
his

> topic.

I don't have the time to prepare such text. Can someone volunteer to submit=
 this text to the WG for review?

EH


--_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FFB23DP3PWEX2MB008ex2se_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











During the IESG review of draft-ietf-oauth-v2, Se=
an Turner raised the following DISCUSS item (meaning, the specification is =
blocked until this is resolved):


 


> 0) General: I found the lack of ABNF somewha=
t disconcerting in that


> implementers would have to hunt through the =
spec to figure out all the


> values of a given field.  For example g=
rant_type has different values based


> on the different kind of access_token reques=
ts - four to be more precise -


> but there's no ABNF for the field.  The=
re are many examples of


> this.   It would greatly aid imple=
menters if a) the ABNF for all fields


> were included in the draft and b) all the AB=
NF was collected in one place.  I


> had individual discusses for each field that=
 had missing ABNF, but it was


> getting out of hand so I'm just going to do =
this one general discuss on this


> topic.


 


I don’t have the time to prepare such text. Ca=
n someone volunteer to submit this text to the WG for review?

 


EH


 






--_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FFB23DP3PWEX2MB008ex2se_--

From bcampbell@pingidentity.com  Mon Apr 23 14:27:13 2012
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 AF08611E808A for ; Mon, 23 Apr 2012 14:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.936
X-Spam-Level: 
X-Spam-Status: No, score=-5.936 tagged_above=-999 required=5 tests=[AWL=0.040,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEqrGixP+ARt for ; Mon, 23 Apr 2012 14:27:13 -0700 (PDT)
Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id A2E7811E8072 for ; Mon, 23 Apr 2012 14:27:12 -0700 (PDT)
Received: from mail-vx0-f179.google.com ([209.85.220.179]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKT5XJMHawxf+aJ8we8fG2yHmy+Z1yqVZj@postini.com; Mon, 23 Apr 2012 14:27:12 PDT
Received: by vcbf11 with SMTP id f11so8552976vcb.10 for ; Mon, 23 Apr 2012 14:27:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=/R9wRMXhKCtmEOSK5IzH0gNaYxDI0f7fP8icoJoEmUE=; b=Rx8W04dG3decelJRIcCa+k30i/1N4TqWjLBokBlTDGZkt21RGY3Hb++I8k5gid1LYW oS1NUmZLqRPq2o6ryjMS0398ZOSIzBJwdO5dUfVjV54IyxXW6nzVGjiLzAaT5VQzINZP ly/UZDjSvbkOqQgPKDHQgzFIilF9cEl0NDOlGoazxf8Bw3XxBcz0cYej4YdpZywRs308 3U7/nUvp+/I3fhHszFCZWhB/q8Vjd/mV0dMiQ5qPqSd6QnTC0pgxlh7NYI7b3IqPXNN5 8KdxF8Rv0Z082B+GWZvMhn9HGas8OnKrlzcjy6hrDfIM+P6LsWx6h5xv/8u19DGgZcuc pfJA==
Received: by 10.220.38.138 with SMTP id b10mr17513383vce.23.1335216431294; Mon, 23 Apr 2012 14:27:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.38.104 with HTTP; Mon, 23 Apr 2012 14:26:41 -0700 (PDT)
From: Brian Campbell 
Date: Mon, 23 Apr 2012 15:26:41 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=bcaec54ee75615e94f04be5f4d4f
X-Gm-Message-State: ALoCoQmeDosUDB2hLbykO7sr2PjBMs3PepVB0a9peGDFjz9bTH5UxqcJG/ivB+0cjsyk5IrI63Nz
Subject: [OAUTH-WG] double normative? (draft-ietf-oauth-assertions WGLC comment V)
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, 23 Apr 2012 21:27:13 -0000

--bcaec54ee75615e94f04be5f4d4f
Content-Type: text/plain; charset=ISO-8859-1

Sections 6.1, 6.2, 6.3 and 6.4 of
http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 are all similar
in that they have a paragraph at the top that ends with, "The following
format and processing rules SHOULD be applied:" followed by a bullet list
of specific rules. However some of the individual bullets themselves have
normative language including several that have a MUST. On rereading the
draft today, I found this to be a little confusing. I mean, what does it
mean to say that you SHOULD MUST do something? At a minimum, it seems like
kind of bad form. I'm thinking that the lead in text before each list
should just say something like "The following format and processing rules
are to be applied:" to avoid any potential logical conflict between the
normative terms. But depending on how the previous text was interpreted,
that could be considered a breaking change? That might be okay though as
this is just an abstract specification. Any thoughts?

--bcaec54ee75615e94f04be5f4d4f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sections 6.1, 6.2, 6.3 and 6.4 of http://tools.ietf.org/html/draft-ietf-oauth-as=
sertions-01 are all similar in that they have a paragraph at the top th=
at ends with, "The following format and
   processing rules SHOULD be applied:" followed by a bullet list of s=
pecific rules. However some of the individual bullets themselves have norma=
tive language including several that have a MUST. On rereading the draft to=
day, I found this to be a little confusing. I mean, what does it mean to sa=
y that you SHOULD MUST do something? At a minimum, it seems like kind of ba=
d form. I'm thinking that the lead in text before each list should just=
 say something like  "The following format and
   processing rules are to be applied:" to avoid any potential logical=
 conflict between the normative terms. But depending on how the previous te=
xt was interpreted, that could be considered a breaking change? That might =
be okay though as this is just an abstract specification. Any thoughts?



--bcaec54ee75615e94f04be5f4d4f--

From bcampbell@pingidentity.com  Mon Apr 23 15:55:27 2012
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 09BEE11E809D for ; Mon, 23 Apr 2012 15:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.938
X-Spam-Level: 
X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hLilenp9io5 for ; Mon, 23 Apr 2012 15:55:26 -0700 (PDT)
Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2C55211E8072 for ; Mon, 23 Apr 2012 15:55:26 -0700 (PDT)
Received: from mail-vb0-f41.google.com ([209.85.212.41]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKT5Xd3WhToeFNOSzTLYQhV+NWQaFxrWOF@postini.com; Mon, 23 Apr 2012 15:55:26 PDT
Received: by vbbey12 with SMTP id ey12so64615vbb.14 for ; Mon, 23 Apr 2012 15:55:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=x95KWIc3VzVSw8GBOHQELjeJNjVyG+eJ6kpqoASLjlk=; b=eB00ZlBQigapGWaBIg6zQxzNNs+tWULqv5Wqc6Ooob8285q1eFxYLsWyfhMVINa2R5 6v300D8uYEfqn7N9ygOqRBmRZY3AaiMe4mBFNV21xGv94HrkdbXYDabpGWIXJ5iCqHuy 1d8Nn7k97q069n/9jrARAIg89Lgc8qIV1zoUqbYVvXVpQQylDyd87j/uXzqXcz3CwFv+ ua7uYYo0Y+BUIFu1nPeuagVdODfv3HAHvHyke0dSPCKP4LLXKlAmZzTo2mei80TLON2p p45nA3Ycpq8LxXnNkJUYetj9YAXPx7mYOZFEZgIkOhACcFuLTB69H7F9W89O7KjmlM60 lG2w==
Received: by 10.52.69.144 with SMTP id e16mr14773183vdu.65.1335221724380; Mon, 23 Apr 2012 15:55:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.38.104 with HTTP; Mon, 23 Apr 2012 15:54:54 -0700 (PDT)
From: Brian Campbell 
Date: Mon, 23 Apr 2012 16:54:54 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=20cf3071cdce93fd0d04be6088a1
X-Gm-Message-State: ALoCoQk/8nO4wJF8cAFU+ZaNENAOE+gLzmWKeAxQlHAz8GryG+LPiVrq58DwLVLsh/yWd4maQoJC
Subject: [OAUTH-WG] draft-ietf-oauth-assertions WGLC comment VI
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, 23 Apr 2012 22:55:27 -0000

--20cf3071cdce93fd0d04be6088a1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The treatment of client_id draft-ietf-oauth-assertions-01 seems a bit
inconsistent/problematic.

=A74.1 & 4.2 say it's OPTIONAL.

=A7's 6.1 and 6.2 have, "The client_id HTTP parameter SHOULD identify the
client to the authorization server" while 6.3 and 6.4 have, "The client_id
HTTP parameter MUST identify the client to the authorization server."  Are
these intended to be the stronger than the optional in the 4.xs?  Or to say
that it should/must identify the client, in the case that the parameter is
present?

I would suggest that all of those except the one in =A74.1 be removed and
that the 4.1 one changed to say,

   "client_id  OPTIONAL.  The client identifier as described in Section 2
      of OAuth 2.0 [I-D.ietf.oauth-v2]. When present, the client_id MUST
(or SHOULD?) identify the client to the authorization server."

That would cover the client authentication cases and defer to the core spec
for authorization cases (thought it's not 100% clear, I think it says or
should say that it's optional in most cases).

I'm not sure if that meets the original intent though?

--20cf3071cdce93fd0d04be6088a1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The treatment of client_id draft-ietf-oauth-assertions-01 seems a bit incon=
sistent/problematic.

=A74.1 & 4.2 say it's OPTIONAL.

=
=A7's 6.1 and 6.2 have, "The client_id HTTP parameter SHOULD ident=
ify the client to the
      authorization server" while 6.3 and 6.4 have, "The client_i=
d HTTP parameter MUST identify the client to the authorization server."=
;=A0 Are these intended to be the stronger than the optional in the 4.xs?=
=A0 Or to say that it should/must identify the client, in the case that the=
 parameter is present?



I would suggest that all of those except the one in =A74.1 be removed a=
nd that the 4.1 one changed to say, 

=A0=A0 "client_id=A0 OPTIO=
NAL.=A0 The client identifier as described in Section 2
=A0=A0=A0=A0=A0 =
of OAuth 2.0 [I-D.ietf.oauth-v2]. When present, the client_id MUST (or SHOU=
LD?) identify the client to the
      authorization server."

That would cover the client authen=
tication cases and defer to the core spec for authorization cases (thought =
it's not 100% clear, I think it says or should say that it's option=
al in most cases).



I'm not sure if that meets the original intent though?


=
=A0=A0=20

--20cf3071cdce93fd0d04be6088a1--

From eran@hueniverse.com  Mon Apr 23 17:12:24 2012
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 556D221F86F2 for ; Mon, 23 Apr 2012 17:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Level: 
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGaEDumIyuoL for ; Mon, 23 Apr 2012 17:12:22 -0700 (PDT)
Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id A0D2C21F86F0 for ; Mon, 23 Apr 2012 17:12:22 -0700 (PDT)
Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id 1cCM1j0070CJzpC01cCMTz; Mon, 23 Apr 2012 17:12:21 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 17:12:21 -0700
From: Eran Hammer 
To: Chuck Canning , "oauth@ietf.org WG (oauth@ietf.org)" 
Thread-Topic: OAuth ABNF
Thread-Index: Ac0hlo/WWuxsG+HsR9eTWVbGALjxfAACUw7AAAO9RrA=
Date: Tue, 24 Apr 2012 00:12:20 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFB712@P3PWEX2MB008.ex2.secureserver.net>
References: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFB23D@P3PWEX2MB008.ex2.secureserver.net> <09F445A2195DAF4FA60A3FC08DF8A67C3A09B3C5@sccorpmail03.mygazoo.com>
In-Reply-To: <09F445A2195DAF4FA60A3FC08DF8A67C3A09B3C5@sccorpmail03.mygazoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FFB712P3PWEX2MB008ex2se_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAuth ABNF
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: Tue, 24 Apr 2012 00:12:24 -0000

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FFB712P3PWEX2MB008ex2se_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We can do both (provide it as defined and in one section). But someone need=
s to prepare all the ABNFs first.

EH

From: Chuck Canning [mailto:Chuck.Canning@deem.com]
Sent: Monday, April 23, 2012 3:28 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: OAuth ABNF

As someone trying to implement the spec, I find that I have to jump around =
the spec to find this information also. Personally, I think grouping the re=
lated options in the document might make it more clear instead of grouping =
it based on a concept and then the next style of flow. It might also help s=
hine light on the holes in the spec or where things are ambiguous or not cl=
early defined. (ie. clearly defining all the options for a particular URI t=
ogether instead of having to jump over multiple sections and mentally compa=
ring each option).

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Eran =
Hammer
Sent: Monday, April 23, 2012 2:20 PM
To: oauth@ietf.org WG (oauth@ietf.org)
Subject: [SPAM] [OAUTH-WG] OAuth ABNF
Importance: Low


During the IESG review of draft-ietf-oauth-v2, Sean Turner raised the follo=
wing DISCUSS item (meaning, the specification is blocked until this is reso=
lved):



> 0) General: I found the lack of ABNF somewhat disconcerting in that

> implementers would have to hunt through the spec to figure out all the

> values of a given field.  For example grant_type has different values bas=
ed

> on the different kind of access_token requests - four to be more precise =
-

> but there's no ABNF for the field.  There are many examples of

> this.   It would greatly aid implementers if a) the ABNF for all fields

> were included in the draft and b) all the ABNF was collected in one place=
.  I

> had individual discusses for each field that had missing ABNF, but it was

> getting out of hand so I'm just going to do this one general discuss on t=
his

> topic.

I don't have the time to prepare such text. Can someone volunteer to submit=
 this text to the WG for review?

EH


--_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FFB712P3PWEX2MB008ex2se_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











We can do both (provid=
e it as defined and in one section). But someone needs to prepare all the A=
BNFs first.


 


EH

 








From: Chuck Ca=
nning [mailto:Chuck.Canning@deem.com]


Sent: Monday, April 23, 2012 3:28 PM

To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)

Subject: RE: OAuth ABNF






 


As someone trying to i=
mplement the spec, I find that I have to jump around the spec to find this =
information also. Personally, I think grouping the related options in the d=
ocument might make it more clear instead
 of grouping it based on a concept and then the next style of flow. It migh=
t also help shine light on the holes in the spec or where things are ambigu=
ous or not clearly defined. (ie. clearly defining all the options for a par=
ticular URI together instead of
 having to jump over multiple sections and mentally comparing each option).=
  


 






From:
oauth-bounces@ietf.org 
[mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer

Sent: Monday, April 23, 2012 2:20 PM

To: oauth@ietf.org WG (oauth@ietf.org)

Subject: [SPAM] [OAUTH-WG] OAuth ABNF

Importance: Low






 


During the IESG review of draft-ietf-oauth-v2, Se=
an Turner raised the following DISCUSS item (meaning, the specification is =
blocked until this is resolved):


 


> 0) General: I found the lack of ABNF somewha=
t disconcerting in that


> implementers would have to hunt through the =
spec to figure out all the


> values of a given field.  For example g=
rant_type has different values based


> on the different kind of access_token reques=
ts - four to be more precise -


> but there's no ABNF for the field.  The=
re are many examples of


> this.   It would greatly aid imple=
menters if a) the ABNF for all fields


> were included in the draft and b) all the AB=
NF was collected in one place.  I


> had individual discusses for each field that=
 had missing ABNF, but it was


> getting out of hand so I'm just going to do =
this one general discuss on this


> topic.


 


I don’t have the time to prepare such text. Ca=
n someone volunteer to submit this text to the WG for review?

 


EH


 








--_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FFB712P3PWEX2MB008ex2se_--

From internet-drafts@ietf.org  Mon Apr 23 18:46:01 2012
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 4E13C21F85CF; Mon, 23 Apr 2012 18:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.548
X-Spam-Level: 
X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ei5uUD5EiRy; Mon, 23 Apr 2012 18:46:00 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4F521F85B1; Mon, 23 Apr 2012 18:46:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.01p1
Message-ID: <20120424014600.2289.60899.idtracker@ietfa.amsl.com>
Date: Mon, 23 Apr 2012 18:46:00 -0700
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt
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: Tue, 24 Apr 2012 01:46:01 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

	Title           : The OAuth 2.0 Authorization Protocol: Bearer Tokens
	Author(s)       : Michael B. Jones
                          Dick Hardt
                          David Recordon
	Filename        : draft-ietf-oauth-v2-bearer-19.txt
	Pages           : 24
	Date            : 2012-04-23

   This specification describes how to use bearer tokens in HTTP
   requests to access OAuth 2.0 protected resources.  Any party in
   possession of a bearer token (a "bearer") can use it to get access to
   the associated resources (without demonstrating possession of a
   cryptographic key).  To prevent misuse, bearer tokens need to be
   protected from disclosure in storage and in transport.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/


From Michael.Jones@microsoft.com  Mon Apr 23 18:59:40 2012
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 56B8121F866C for ; Mon, 23 Apr 2012 18:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.898
X-Spam-Level: 
X-Spam-Status: No, score=-3.898 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN9C-QygUgfs for ; Mon, 23 Apr 2012 18:59:35 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC8B21F861A for ; Mon, 23 Apr 2012 18:59:35 -0700 (PDT)
Received: from mail134-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Apr 2012 01:59:34 +0000
Received: from mail134-va3 (localhost [127.0.0.1])	by mail134-va3-R.bigfish.com (Postfix) with ESMTP id 7D6EC4E019B; Tue, 24 Apr 2012 01:59:34 +0000 (UTC)
X-SpamScore: -19
X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail134-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail134-va3 (localhost.localdomain [127.0.0.1]) by mail134-va3 (MessageSwitch) id 1335232771713161_9057; Tue, 24 Apr 2012 01:59:31 +0000 (UTC)
Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.240])	by mail134-va3.bigfish.com (Postfix) with ESMTP id 9DF6D1A0049; Tue, 24 Apr 2012 01:59:31 +0000 (UTC)
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Apr 2012 01:59:31 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0283.004; Tue, 24 Apr 2012 01:59:30 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: OAuth 2.0 Bearer Token Specification Draft -19
Thread-Index: Ac0hveIUkpPABtgkSnu5nhGYww/Seg==
Date: Tue, 24 Apr 2012 01:59:29 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436649611E@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.78]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436649611ETK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "presnick@qualcomm.com" , "housley@vigilsec.com" 
Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -19
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: Tue, 24 Apr 2012 01:59:40 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436649611ETK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Draft 19 of the OAuth 2.0 Bearer Token Specification has been published.  A=
ddressed DISCUSS issues and comments raised for which resolutions have been=
 agreed to.  No normative changes were made.  Changes made were:
*         Use ABNF from RFC 5234.
*         Added sentence "The Bearer authentication scheme is intended prim=
arily for server authentication using the WWW-Authenticate and Authorizatio=
n HTTP headers, but does not preclude its use for proxy authentication" to =
the introduction.
*         In the introduction, state that this document also imposes semant=
ic requirements upon the access token.
*         Reference the scope definition in the OAuth core spec.
*         Added scope examples.
*         Reference RFC 6265 for security considerations about cookies.

The draft is available at:

*         http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19
A HTML-formatted version is available at:

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-19.html

                                                                -- Mike


--_000_4E1F6AAD24975D4BA5B16804296739436649611ETK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Draft 19 of the OAuth 2.0 Bearer Token Specification=
 has been published.  Addressed DISCUSS issues and comments raised for=
 which resolutions have been agreed to.  No normative changes were mad=
e.  Changes made were:




·     &=
nbsp;  
Use ABN=
F from RFC 5234.




·     &=
nbsp;  
Added s=
entence "The Bearer authentication scheme is intended primarily for se=
rver authentication using the WWW-Authenticate and Authorization
 HTTP headers, but does not preclude its use for proxy authentication"=
 to the introduction.




·     &=
nbsp;  
In the =
introduction, state that this document also imposes semantic requirements u=
pon the access token.




·     &=
nbsp;  
Referen=
ce the
scope definition in the OAuth core spec.




·     &=
nbsp;  
Added
scope examples.




·     &=
nbsp;  
Referen=
ce RFC 6265 for security considerations about cookies.



 


The draft is available at:


·        
http://tools.ietf.org/html/draft-ietf-oauth-v2-bea=
rer-19


A HTML-formatted version is available at:=



·        
http://self-issued.info/docs/draft-ietf-oau=
th-v2-bearer-19.html


 


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     -- Mike


 






--_000_4E1F6AAD24975D4BA5B16804296739436649611ETK5EX14MBXC284r_--

From squid3@treenet.co.nz  Mon Apr 23 19:10:11 2012
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 AAA0F21F870E for ; Mon, 23 Apr 2012 19:10:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.429
X-Spam-Level: 
X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[AWL=-4.767, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x95AWEp3Nu5G for ; Mon, 23 Apr 2012 19:10:10 -0700 (PDT)
Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0B20E21F8700 for ; Mon, 23 Apr 2012 19:10:09 -0700 (PDT)
Received: by treenet.co.nz (Postfix, from userid 33) id E7E23E6E76; Tue, 24 Apr 2012 14:10:06 +1200 (NZST)
To: 
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 24 Apr 2012 14:10:05 +1200
From: Amos Jeffries 
In-Reply-To: <20120424014600.2289.60899.idtracker@ietfa.amsl.com>
References: <20120424014600.2289.60899.idtracker@ietfa.amsl.com>
Message-ID: <5ad1b8b31aa38e4c0ab3c8012a1b8290@treenet.co.nz>
X-Sender: squid3@treenet.co.nz
User-Agent: Roundcube Webmail/0.7.1
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt
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: Tue, 24 Apr 2012 02:10:11 -0000

On 24.04.2012 13:46, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Web Authorization
> Protocol Working Group of the IETF.
>
> 	Title           : The OAuth 2.0 Authorization Protocol: Bearer 
> Tokens
> 	Author(s)       : Michael B. Jones
>                           Dick Hardt
>                           David Recordon
> 	Filename        : draft-ietf-oauth-v2-bearer-19.txt
> 	Pages           : 24
> 	Date            : 2012-04-23
>
>    This specification describes how to use bearer tokens in HTTP
>    requests to access OAuth 2.0 protected resources.  Any party in
>    possession of a bearer token (a "bearer") can use it to get access 
> to
>    the associated resources (without demonstrating possession of a
>    cryptographic key).  To prevent misuse, bearer tokens need to be
>    protected from disclosure in storage and in transport.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt



The section 2.3 (URL Query Parameter) text is still lacking explicit 
and specific security requirements. The overarching TLS requirement is 
good in general, but insufficient in the presence of HTTP intermediaries 
on the TLS connection path as is becoming a common practice.

The upcoming HTTPbis specs document this issue as a requirement for new 
auth schemes such as Bearer:

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1
"
       Therefore, new authentication schemes which choose not to carry
       credentials in the Authorization header (e.g., using a newly
       defined header) will need to explicitly disallow caching, by
       mandating the use of either Cache-Control request directives
       (e.g., "no-store") or response directives (e.g., "private").
"


AYJ


From Michael.Jones@microsoft.com  Mon Apr 23 21:33:46 2012
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 26F2821F846D for ; Mon, 23 Apr 2012 21:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.947
X-Spam-Level: 
X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahfy-xsCXIDi for ; Mon, 23 Apr 2012 21:33:44 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id F062F21F846C for ; Mon, 23 Apr 2012 21:33:43 -0700 (PDT)
Received: from mail70-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Apr 2012 04:33:43 +0000
Received: from mail70-ch1 (localhost [127.0.0.1])	by mail70-ch1-R.bigfish.com (Postfix) with ESMTP id D12B41A006F; Tue, 24 Apr 2012 04:33:42 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail70-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail70-ch1 (localhost.localdomain [127.0.0.1]) by mail70-ch1 (MessageSwitch) id 1335242021166333_18551; Tue, 24 Apr 2012 04:33:41 +0000 (UTC)
Received: from CH1EHSMHS009.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242])	by mail70-ch1.bigfish.com (Postfix) with ESMTP id 1C5792006B; Tue, 24 Apr 2012 04:33:41 +0000 (UTC)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Apr 2012 04:33:39 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0298.005; Tue, 24 Apr 2012 04:33:21 +0000
From: Mike Jones 
To: Amos Jeffries , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt
Thread-Index: AQHNIbwgV4Z9yviFHUqw21P4ROZriJapO0KAgAAn49A=
Date: Tue, 24 Apr 2012 04:33:21 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436649663E@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20120424014600.2289.60899.idtracker@ietfa.amsl.com> <5ad1b8b31aa38e4c0ab3c8012a1b8290@treenet.co.nz>
In-Reply-To: <5ad1b8b31aa38e4c0ab3c8012a1b8290@treenet.co.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.33]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt
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: Tue, 24 Apr 2012 04:33:46 -0000

What specific language would you suggest be added to what section(s)?

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A=
mos Jeffries
Sent: Monday, April 23, 2012 7:10 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt

On 24.04.2012 13:46, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories. This draft is a work item of the Web Authorization=20
> Protocol Working Group of the IETF.
>
> 	Title           : The OAuth 2.0 Authorization Protocol: Bearer=20
> Tokens
> 	Author(s)       : Michael B. Jones
>                           Dick Hardt
>                           David Recordon
> 	Filename        : draft-ietf-oauth-v2-bearer-19.txt
> 	Pages           : 24
> 	Date            : 2012-04-23
>
>    This specification describes how to use bearer tokens in HTTP
>    requests to access OAuth 2.0 protected resources.  Any party in
>    possession of a bearer token (a "bearer") can use it to get access=20
> to
>    the associated resources (without demonstrating possession of a
>    cryptographic key).  To prevent misuse, bearer tokens need to be
>    protected from disclosure in storage and in transport.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt



The section 2.3 (URL Query Parameter) text is still lacking explicit and sp=
ecific security requirements. The overarching TLS requirement is good in ge=
neral, but insufficient in the presence of HTTP intermediaries on the TLS c=
onnection path as is becoming a common practice.

The upcoming HTTPbis specs document this issue as a requirement for new aut=
h schemes such as Bearer:

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1
"
       Therefore, new authentication schemes which choose not to carry
       credentials in the Authorization header (e.g., using a newly
       defined header) will need to explicitly disallow caching, by
       mandating the use of either Cache-Control request directives
       (e.g., "no-store") or response directives (e.g., "private").
"


AYJ

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



From squid3@treenet.co.nz  Mon Apr 23 22:13:13 2012
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 6F9CA21F864A for ; Mon, 23 Apr 2012 22:13:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.488
X-Spam-Level: 
X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[AWL=-4.826, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KagQXoiZXcZI for ; Mon, 23 Apr 2012 22:13:13 -0700 (PDT)
Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFD221F85FF for ; Mon, 23 Apr 2012 22:13:10 -0700 (PDT)
Received: from [10.1.1.14] (unknown [119.224.40.49]) by treenet.co.nz (Postfix) with ESMTP id 071F4E6E76; Tue, 24 Apr 2012 17:13:07 +1200 (NZST)
Message-ID: <4F963662.3050707@treenet.co.nz>
Date: Tue, 24 Apr 2012 17:13:06 +1200
From: Amos Jeffries 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Mike Jones 
References: <20120424014600.2289.60899.idtracker@ietfa.amsl.com> <5ad1b8b31aa38e4c0ab3c8012a1b8290@treenet.co.nz> <4E1F6AAD24975D4BA5B16804296739436649663E@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436649663E@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt
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: Tue, 24 Apr 2012 05:13:13 -0000

On 24/04/2012 4:33 p.m., Mike Jones wrote:
> What specific language would you suggest be added to what section(s)?
>
> 				-- Mike


Perhapse the last paragraph appended:
"

    Because of the security weaknesses associated with the URI method
    (see Section 5), including the high likelihood that the URL
    containing the access token will be logged, it SHOULD NOT be used
    unless it is impossible to transport the access token in the
    "Authorization" request header field or the HTTP request entity-body.
    Resource servers compliant with this specification MAY support this
    method.

    Clients requesting URL containing the access token MUST also send a
    Cache-Control header containing the "no-store" option. Server success
    (2xx status) responses to these requests MUST contain a Cache-Control
    header with the "private" option.

"

I'm a little suspicious that the "SHOUDL NOT" in that top paragraph likely should be a MUST NOT to further discourage needless use.


AYJ


>
> -----Original Message-----
> From: oauth-bounces@ietf.org On Behalf Of Amos Jeffries
> Sent: Monday, April 23, 2012 7:10 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt
>
> On 24.04.2012 13:46, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Web Authorization
>> Protocol Working Group of the IETF.
>>
>> 	Title           : The OAuth 2.0 Authorization Protocol: Bearer
>> Tokens
>> 	Author(s)       : Michael B. Jones
>>                            Dick Hardt
>>                            David Recordon
>> 	Filename        : draft-ietf-oauth-v2-bearer-19.txt
>> 	Pages           : 24
>> 	Date            : 2012-04-23
>>
>>     This specification describes how to use bearer tokens in HTTP
>>     requests to access OAuth 2.0 protected resources.  Any party in
>>     possession of a bearer token (a "bearer") can use it to get access
>> to
>>     the associated resources (without demonstrating possession of a
>>     cryptographic key).  To prevent misuse, bearer tokens need to be
>>     protected from disclosure in storage and in transport.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt
>
>
> The section 2.3 (URL Query Parameter) text is still lacking explicit and specific security requirements. The overarching TLS requirement is good in general, but insufficient in the presence of HTTP intermediaries on the TLS connection path as is becoming a common practice.
>
> The upcoming HTTPbis specs document this issue as a requirement for new auth schemes such as Bearer:
>
> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1
> "
>         Therefore, new authentication schemes which choose not to carry
>         credentials in the Authorization header (e.g., using a newly
>         defined header) will need to explicitly disallow caching, by
>         mandating the use of either Cache-Control request directives
>         (e.g., "no-store") or response directives (e.g., "private").
> "
>
>
> AYJ
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


From paulej@packetizer.com  Mon Apr 23 22:56:32 2012
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 809C521F853C; Mon, 23 Apr 2012 22:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.376
X-Spam-Level: 
X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWZcJYdqsGwj; Mon, 23 Apr 2012 22:56:31 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7521321F853B; Mon, 23 Apr 2012 22:56:31 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q3O5uSxP001046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Apr 2012 01:56:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335246990; bh=cNNYrDneXsrEue0Lb9FEMYqmN+5GR/Svy5NLDBci9+g=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=SyipDHmSqaJ/d54KpnJzKr+Fwih0gmNUSx4wJlQg6onEBa6+p16z3e4Do6sjG63xB W7kXayPqClRaff1k8nWpU/33xcrA200eM+nRYAWCyY2SrFg7K5CzgNqEyGrS1gxvhW fv2po9trH4qqCbzM4mswiZdduECPolHNt7fOCKO8=
From: "Paul E. Jones" 
To: "'Michael Thomas'" , "'Derek Atkins'" 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net>	<4F8852D0.4020404@cs.tcd.ie>	<9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>		<9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com>	<4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com>	<091401cd1ea3$e159be70$a40d3b50$@packetizer.com>		<091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>	 <4F917545.5080103@mtcc.com>  <4F9573D6.9080603@mtcc.com>
In-Reply-To: <4F9573D6.9080603@mtcc.com>
Date: Tue, 24 Apr 2012 01:56:32 -0400
Message-ID: <027701cd21df$0179de40$046d9ac0$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIAfr0IMYFP+Nqgkj5c4C1LFLKQ8QHu47mLATII4l0DGXo5TgGHkeTZAgqoPTsBaa3oyAIw2f/NAUQ5aEgCO5nRqQLuh1nuApXB+mECb+r+0JV73h6g
Content-Language: en-us
Cc: 'Tim Bray' , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Tue, 24 Apr 2012 05:56:32 -0000

Michael,

>  From a programming standpoint, JSON is just easier to deal with. Consider
> these two links:
> 
> http://php.net/manual/en/book.json.php
> 
> http://php.net/manual/en/book.xml.php
> 
> and tell me which you'd rather deal with. It's not huge, but it's not
> nothing either.

To be fair, this works well partly because of the language.  Works even
better in JavaScript.  It would work less well in C.  Here's just one
example:
http://www.digip.org/jansson/doc/2.3/

JSON bits do not map perfectly to C.  I thought C++ might be simpler, but
the first library I grabbed had library documentation that was 224 pages
long (libjson).

When I process simple XML like that from WebFinger, I tend to use a parser
that just steps through each node in order.  I don't need to decode the
whole "document" in memory and reference pieces and parts of it: one pass
over it and I grab what I need.  It's very simple to process the XML output
from WebFinger that way.

Paul



From mark.mcgloin@ie.ibm.com  Tue Apr 24 01:17:40 2012
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 8E3C821F8713 for ; Tue, 24 Apr 2012 01:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+MPhfQ5QD2H for ; Tue, 24 Apr 2012 01:17:38 -0700 (PDT)
Received: from e06smtp16.uk.ibm.com (e06smtp16.uk.ibm.com [195.75.94.112]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6F421F86B9 for ; Tue, 24 Apr 2012 01:17:37 -0700 (PDT)
Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Tue, 24 Apr 2012 09:17:36 +0100
Received: from d06nrmr1307.portsmouth.uk.ibm.com (9.149.38.129) by e06smtp16.uk.ibm.com (192.168.101.146) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Tue, 24 Apr 2012 09:17:33 +0100
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3O8HXPt2486452; Tue, 24 Apr 2012 09:17:33 +0100
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3O8HVZA002382; Tue, 24 Apr 2012 02:17:31 -0600
Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3O8HVex002374; Tue, 24 Apr 2012 02:17:31 -0600
In-Reply-To: <4F957EA7.3060004@mtcc.com>
References: 	<4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>
X-KeepSent: 3ECF645E:478720A4-802579EA:002D0B13; type=4; name=$KeepSent
To: Michael Thomas 
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: 
From: Mark Mcgloin 
Date: Tue, 24 Apr 2012 09:17:24 +0100
X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 24/04/2012 09:17:25
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
x-cbid: 12042408-3548-0000-0000-000001B54537
Cc: Barry Leiba , "oauth@ietf.org" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 08:17:40 -0000

Hi Thomas

Your additional text is already covered in a countermeasure for section
4.1.4.  In addition, section 4.1.4.4 states the assumption that the auth
server can't protect against a user installing a malicious client

Regards
Mark

oauth-bounces@ietf.org wrote on 23/04/2012 17:09:11:

> From:
>
> Michael Thomas 
>
> To:
>
> Barry Leiba , "oauth@ietf.org" 
>
> Date:
>
> 23/04/2012 17:09
>
> Subject:
>
> Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
>
> Sent by:
>
> oauth-bounces@ietf.org
>
> [I accidentally sent just to Barry my take on his addition which I
> think is fine
> except for one thing addition...]
>
> Barry Leiba wrote:
> > You sent it just to me.  I think it's a reasonable addition, so please
> > send it to the distribution (which at the moment does not include the
> > OAuth list, just the
> >  alias), and
> > suggest specific text to add.  I presume it would go in an new bullet
> > just before the last.
>
> The thing I think is missing here is that the Authorization Server has a
> stake in mitigating threats, and actually has a quite potent one: it can
> be selective with whom it enrolls, and can revoke bad actors.
>
> So let me try a bullet:
>
> o While end users are mostly incapable of properly vetting applications
they
>    load onto their devices, those who deploy Authorization Servers
> have tools at
>    their disposal to mitigate malicious Clients. Namely, in order to
> become a threat
>    at all, a Client must first become a Client. A well run
> Authorization Server MAY
>    require a curation process when enrolling Clients, and SHOULD
> have processes to
>    revoke bad actors after enrollment.
>
> Mike
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


From mike@mtcc.com  Tue Apr 24 06:24:56 2012
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 9331221F8824; Tue, 24 Apr 2012 06:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aaFtOuDiZsC; Tue, 24 Apr 2012 06:24:56 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id ED28421F8808; Tue, 24 Apr 2012 06:24:55 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3ODOler014390 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 06:24:48 -0700
Message-ID: <4F96A99F.7010303@mtcc.com>
Date: Tue, 24 Apr 2012 06:24:47 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Mark Mcgloin 
References: 	<4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=744; t=1335273888; x=1336137888; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20Shepherd=20review=20of=20d raft-ietf-oauth-v2-threatmodel |Sender:=20 |To:=20Mark=20Mcgloin=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=s3COoTshgoFdc7FfZwk0Om1K+yfLeNBedValtiY+xSo=; b=gwNEJnBr5Jf2o4ylcjtKOXnzcdBRd2uaYz51UsEx9o07X+UiBL4CmcqtrU sMrfeRZSPU9Jq9TsAJN1Zj24T/mMvgev/V/8VSv0f24p7F3ILRgX6VYMRLEZ KRHfW4GEEg7B+zhgqBagj3A/yGq66zeh8YHTFR4KsrfQMZiVpRlDk=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: Barry Leiba , "oauth@ietf.org" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 13:24:56 -0000

On 04/24/2012 01:17 AM, Mark Mcgloin wrote:
> Hi Thomas
>
> Your additional text is already covered in a countermeasure for section
> 4.1.4.  In addition, section 4.1.4.4 states the assumption that the auth
> server can't protect against a user installing a malicious client
>

The more I read this draft, the more borked I think its base assumptions
are. The client *is* one of the main threats. Full stop. A threat document
should not be asking the adversary to play nice. Yet, 4.1.4 bullets 1 and
3 are doing exactly that again. If those are countermeasures, then so is
visualizing world peace.

As for bullet two, it doesn't mention revocation, and I prefer Barry's
section generally. I can't find a section 4.1.4.4

Mike

From mark.mcgloin@ie.ibm.com  Tue Apr 24 07:10:37 2012
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 B819F21F87A9 for ; Tue, 24 Apr 2012 07:10:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZvIzAT9H2rs for ; Tue, 24 Apr 2012 07:10:37 -0700 (PDT)
Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by ietfa.amsl.com (Postfix) with ESMTP id D377921F87A7 for ; Tue, 24 Apr 2012 07:10:36 -0700 (PDT)
Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Tue, 24 Apr 2012 15:10:30 +0100
Received: from d06nrmr1806.portsmouth.uk.ibm.com (9.149.39.193) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Tue, 24 Apr 2012 15:10:28 +0100
Received: from d06av12.portsmouth.uk.ibm.com (d06av12.portsmouth.uk.ibm.com [9.149.37.247]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3OEAST42715656; Tue, 24 Apr 2012 15:10:28 +0100
Received: from d06av12.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3OEARb6027059; Tue, 24 Apr 2012 08:10:27 -0600
Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3OEARTp027052; Tue, 24 Apr 2012 08:10:27 -0600
In-Reply-To: <4F96A99F.7010303@mtcc.com>
References: 	<4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com>
X-KeepSent: 827108F6:2A40EB27-802579EA:004D6EF2; type=4; name=$KeepSent
To: Michael Thomas 
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: 
From: Mark Mcgloin 
Date: Tue, 24 Apr 2012 15:10:20 +0100
X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 24/04/2012 15:10:20
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
x-cbid: 12042414-8372-0000-0000-0000025C6F73
Cc: Barry Leiba , "oauth@ietf.org" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 14:10:37 -0000

Michael Thomas  wrote on 24/04/2012 14:24:47:

>
> Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
>
> On 04/24/2012 01:17 AM, Mark Mcgloin wrote:
> > Hi Thomas
> >
> > Your additional text is already covered in a countermeasure for section
> > 4.1.4.  In addition, section 4.1.4.4 states the assumption that the
auth
> > server can't protect against a user installing a malicious client
> >
>
> The more I read this draft, the more borked I think its base assumptions
> are. The client *is* one of the main threats. Full stop. A threat
document
> should not be asking the adversary to play nice. Yet, 4.1.4 bullets 1 and
> 3 are doing exactly that again. If those are countermeasures, then so is
> visualizing world peace.
>

Irrelevant - we are only discussing bullet 2

> As for bullet two, it doesn't mention revocation, and I prefer Barry's
> section generally. I can't find a section 4.1.4.4
>

Sorry, section 4.4.1.4, not section 4.1.4.4. It is implicit that bad
clients will be revoked - for brevity sake, we don't need to spell that
out.

> Mike
>


From phil.hunt@oracle.com  Tue Apr 24 07:58:02 2012
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 073CD21F87FB; Tue, 24 Apr 2012 07:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yr3cj-iDM8SR; Tue, 24 Apr 2012 07:58:01 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 796C821F87E0; Tue, 24 Apr 2012 07:58:01 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3OEvqol014343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Apr 2012 14:57:53 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q3OEvp51014138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 14:57:52 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3OEvpHh001207; Tue, 24 Apr 2012 09:57:51 -0500
Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Apr 2012 07:57:51 -0700
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com>
In-Reply-To: <4F96A99F.7010303@mtcc.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com>
X-Mailer: iPhone Mail (9B179)
From: Phil Hunt 
Date: Tue, 24 Apr 2012 07:58:53 -0700
To: Michael Thomas 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Barry Leiba , "oauth@ietf.org" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 14:58:02 -0000

Are we at this stage re-opening the entire document? I thought we were respo=
nding only to specific shepherd text edits.=20

Phil

On 2012-04-24, at 6:24, Michael Thomas  wrote:

> On 04/24/2012 01:17 AM, Mark Mcgloin wrote:
>> Hi Thomas
>>=20
>> Your additional text is already covered in a countermeasure for section
>> 4.1.4.  In addition, section 4.1.4.4 states the assumption that the auth
>> server can't protect against a user installing a malicious client
>>=20
>=20
> The more I read this draft, the more borked I think its base assumptions
> are. The client *is* one of the main threats. Full stop. A threat document=

> should not be asking the adversary to play nice. Yet, 4.1.4 bullets 1 and
> 3 are doing exactly that again. If those are countermeasures, then so is
> visualizing world peace.
>=20
> As for bullet two, it doesn't mention revocation, and I prefer Barry's
> section generally. I can't find a section 4.1.4.4
>=20
> Mike
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From mike@mtcc.com  Tue Apr 24 08:05:51 2012
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 C084621F85F1; Tue, 24 Apr 2012 08:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4nq2y2dKj7A; Tue, 24 Apr 2012 08:05:51 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2235121F85DB; Tue, 24 Apr 2012 08:05:51 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3OF5i9U017172 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 08:05:45 -0700
Message-ID: <4F96C148.6010408@mtcc.com>
Date: Tue, 24 Apr 2012 08:05:44 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Mark Mcgloin 
References: 	<4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1074; t=1335279945; x=1336143945; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20Shepherd=20review=20of=20d raft-ietf-oauth-v2-threatmodel |Sender:=20 |To:=20Mark=20Mcgloin=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ENjkIn0r+VUHx2HT5SnZjUQGQIpgX5GiKoWTRlgncnw=; b=mmZ4jE9q6etQXyucM8Lqh/Rptu70ssq+IxblhxrStf7pfTm6XAEG8EFn24 DYWyR8C0UMd7/T2+1wqq2reN5hShKM6yY/iGhMy87g2f7HtnCe+nnZuMufYX gsbGqG8WgUhcQuobtrf/40nLK9L/QCfAE+lRIRDzLH12wFDOKMxhI=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: Barry Leiba , "oauth@ietf.org" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 15:05:51 -0000

On 04/24/2012 07:10 AM, Mark Mcgloin wrote:
> Michael Thomas  wrote on 24/04/2012 14:24:47:
>
>
> The more I read this draft, the more borked I think its base assumptions
> are. The client *is* one of the main threats. Full stop. A threat
> document
>> should not be asking the adversary to play nice. Yet, 4.1.4 bullets 1 and
>> 3 are doing exactly that again. If those are countermeasures, then so is
>> visualizing world peace.
>>
> Irrelevant - we are only discussing bullet 2

Barry: to the extent that your shepherd's review was to take into
account my last call comments which went unanswered, this was
part of my last call comments and obviously haven't been accounted
for. Removing useless countermeasures from this document was part
of what I asked for and I still ask for.

I remain very disturbed by the prickliness of adding text that point
out the shortcomings of oauth in embedded/app environments or
removing supposed mitigations that are not plausible.  This is a
threat document, not a sales booster pamphlet.

Mike


From eran@hueniverse.com  Tue Apr 24 09:20:48 2012
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 5DA4721F8589 for ; Tue, 24 Apr 2012 09:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level: 
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx25MjnZGbHI for ; Tue, 24 Apr 2012 09:20:47 -0700 (PDT)
Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4519321F8584 for ; Tue, 24 Apr 2012 09:20:47 -0700 (PDT)
Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id 1sLm1j0050Dcg9U01sLmjX; Tue, 24 Apr 2012 09:20:46 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Tue, 24 Apr 2012 09:20:46 -0700
From: Eran Hammer 
To: "oauth-chairs@tools.ietf.org" 
Thread-Topic: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
Thread-Index: AQHNIfK7r7KmwuXA4kSoc9MS46QExJaqbLCAgAAaSoD//6DfUA==
Date: Tue, 24 Apr 2012 16:20:46 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net>
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com>
In-Reply-To: <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 16:20:48 -0000

We've been kicking this can of silliness for months now because one person =
refuses to move on even in the face of otherwise unanimous consensus from t=
he group.

Chairs - Please take this ridiculous and never ending thread off list and r=
esolve it once and for all.

EH

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Phil Hunt
> Sent: Tuesday, April 24, 2012 7:59 AM
> To: Michael Thomas
> Cc: Barry Leiba; oauth@ietf.org; oauth-bounces@ietf.org
> Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-
> threatmodel
>=20
> Are we at this stage re-opening the entire document? I thought we were
> responding only to specific shepherd text edits.
>=20
> Phil
>=20
> On 2012-04-24, at 6:24, Michael Thomas  wrote:
>=20
> > On 04/24/2012 01:17 AM, Mark Mcgloin wrote:
> >> Hi Thomas
> >>
> >> Your additional text is already covered in a countermeasure for
> >> section 4.1.4.  In addition, section 4.1.4.4 states the assumption
> >> that the auth server can't protect against a user installing a
> >> malicious client
> >>
> >
> > The more I read this draft, the more borked I think its base
> > assumptions are. The client *is* one of the main threats. Full stop. A
> > threat document should not be asking the adversary to play nice. Yet,
> > 4.1.4 bullets 1 and
> > 3 are doing exactly that again. If those are countermeasures, then so
> > is visualizing world peace.
> >
> > As for bullet two, it doesn't mention revocation, and I prefer Barry's
> > section generally. I can't find a section 4.1.4.4
> >
> > Mike
> > _______________________________________________
> > 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

From mike@mtcc.com  Tue Apr 24 09:27:55 2012
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 1D7E321F8650 for ; Tue, 24 Apr 2012 09:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nfx3Ph55slOq for ; Tue, 24 Apr 2012 09:27:54 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 5C68C21F864C for ; Tue, 24 Apr 2012 09:27:54 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3OGRpk5016090 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 09:27:51 -0700
Message-ID: <4F96D487.1080501@mtcc.com>
Date: Tue, 24 Apr 2012 09:27:51 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Eran Hammer 
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net>
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2429; t=1335284872; x=1336148872; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20Shepherd=20review=20of=20d raft-ietf-oauth-v2-threatmodel |Sender:=20 |To:=20Eran=20Hammer=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=AiYfszAir0NTh1epeec48cApx3HoSwTgmOZzDv5Lsto=; b=tdDF+ZWBVCY1SKdlERL4Oe0eb2gTeN6PbjtJW7+9cOOUR4nveKimq55Z0R hKNNvsrzaofjGOH3+UF0qnMQz5SWwzJQQobSMcD0BySnQacJ10diAHCIS7SO M+JxgIxRCw4PuWP05fNMrmRgmixVkaO8QlhMQlkasvOb5IOzG3upU=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 16:27:55 -0000

I am sorry that you feel the need to resort to an ad hominem attack,
but my last call comment were not addressed in last call, and this
is the process Barry came up with dealing with them.

And it was hardly "unanimous" and you have no say in determining
consensus so stop presuming to do so.

Mike


On 04/24/2012 09:20 AM, Eran Hammer wrote:
> We've been kicking this can of silliness for months now because one person refuses to move on even in the face of otherwise unanimous consensus from the group.
>
> Chairs - Please take this ridiculous and never ending thread off list and resolve it once and for all.
>
> EH
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Phil Hunt
>> Sent: Tuesday, April 24, 2012 7:59 AM
>> To: Michael Thomas
>> Cc: Barry Leiba; oauth@ietf.org; oauth-bounces@ietf.org
>> Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-
>> threatmodel
>>
>> Are we at this stage re-opening the entire document? I thought we were
>> responding only to specific shepherd text edits.
>>
>> Phil
>>
>> On 2012-04-24, at 6:24, Michael Thomas  wrote:
>>
>>> On 04/24/2012 01:17 AM, Mark Mcgloin wrote:
>>>> Hi Thomas
>>>>
>>>> Your additional text is already covered in a countermeasure for
>>>> section 4.1.4.  In addition, section 4.1.4.4 states the assumption
>>>> that the auth server can't protect against a user installing a
>>>> malicious client
>>>>
>>> The more I read this draft, the more borked I think its base
>>> assumptions are. The client *is* one of the main threats. Full stop. A
>>> threat document should not be asking the adversary to play nice. Yet,
>>> 4.1.4 bullets 1 and
>>> 3 are doing exactly that again. If those are countermeasures, then so
>>> is visualizing world peace.
>>>
>>> As for bullet two, it doesn't mention revocation, and I prefer Barry's
>>> section generally. I can't find a section 4.1.4.4
>>>
>>> Mike
>>> _______________________________________________
>>> 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


From kevinmarks@gmail.com  Tue Apr 24 09:43:10 2012
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 5010E21F8702; Tue, 24 Apr 2012 09:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd7UaKa8oOkk; Tue, 24 Apr 2012 09:43:08 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1A521F8709; Tue, 24 Apr 2012 09:43:08 -0700 (PDT)
Received: by qaea16 with SMTP id a16so229355qae.10 for ; Tue, 24 Apr 2012 09:43:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wIcTNmGW8GGvGrY6+Je6twrKi+MbHjuZsKRxVJWc34I=; b=kEIfkRSp98CZOsV3o6VuU2lR/xSYw84D1kDvQYfnjSPlGQwihIMs95cRxzPbxhqxjT 8eKqQ7uobf4vebIMmHxOijS2ZtTmHJtk4fELrd1VkY2WJr6S1QOCgpgpfhOWpuRNrQzM K3rjU5ka+gVzpSz43O445Tub1rtoZCk06WopWmLlaBNvAOP8R5JKWDDZiQmkR13VTK1N dxrCXIiAhCz4s36oGDoxcvajQfjz1Y95v3VLX0lrAaWCgbvg2d3zLaxt6nYMU2ICNCGv Af7vyRgh3I6rLmKfKefMm3e+XFpvZshvbh087zLwX8Nq5FPZadBZa67j6eiJbWbSrYDe 6lGg==
MIME-Version: 1.0
Received: by 10.224.209.4 with SMTP id ge4mr17423301qab.12.1335285788085; Tue, 24 Apr 2012 09:43:08 -0700 (PDT)
Received: by 10.229.138.77 with HTTP; Tue, 24 Apr 2012 09:43:07 -0700 (PDT)
In-Reply-To: <027701cd21df$0179de40$046d9ac0$@packetizer.com>
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>  <4F9573D6.9080603@mtcc.com> <027701cd21df$0179de40$046d9ac0$@packetizer.com>
Date: Tue, 24 Apr 2012 09:43:07 -0700
Message-ID: 
From: Kevin Marks 
To: "Paul E. Jones" 
Content-Type: multipart/alternative; boundary=20cf300fab73128cb404be6f736f
Cc: Tim Bray , Derek Atkins , oauth@ietf.org, Apps Discuss 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Tue, 24 Apr 2012 16:43:10 -0000

--20cf300fab73128cb404be6f736f
Content-Type: text/plain; charset=UTF-8

I think you make JSON's point for it. It has a single, unambiguous,
bidirectional mapping to native data structures in all dynamic languages;
indeed that is its design goal.

XML does not map well to language structures, except in languages designed
explicitly to manipulate it. The duality of elements and attributes means
additional choices at each encode/decode boundary, and guaranteed ambiguity.

To continue the argument made by mark Nottingham and Tim Bray, having to
choose between attributes and elements at each point imposes the same
overhead at a different layer than having to choose between xml and json.

Yes, this natural mapping does not hold true for C, because C doesn't have
a native dictionary/hashtag data structure. C doesn't make XML or anything
else easy either, but C programmers are used to that.

On Mon, Apr 23, 2012 at 10:56 PM, Paul E. Jones wrote:

> Michael,
>
> >  From a programming standpoint, JSON is just easier to deal with.
> Consider
> > these two links:
> >
> > http://php.net/manual/en/book.json.php
> >
> > http://php.net/manual/en/book.xml.php
> >
> > and tell me which you'd rather deal with. It's not huge, but it's not
> > nothing either.
>
> To be fair, this works well partly because of the language.  Works even
> better in JavaScript.  It would work less well in C.  Here's just one
> example:
> http://www.digip.org/jansson/doc/2.3/
>
> JSON bits do not map perfectly to C.  I thought C++ might be simpler, but
> the first library I grabbed had library documentation that was 224 pages
> long (libjson).
>
> When I process simple XML like that from WebFinger, I tend to use a parser
> that just steps through each node in order.  I don't need to decode the
> whole "document" in memory and reference pieces and parts of it: one pass
> over it and I grab what I need.  It's very simple to process the XML output
> from WebFinger that way.
>
> Paul
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--20cf300fab73128cb404be6f736f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I think you make JSON's point for it. It has=
 a single, unambiguous, bidirectional mapping to native data structures in =
all dynamic languages; indeed that is its design goal.


XML does not map well to language stru=
ctures, except in languages designed explicitly to manipulate it. The duali=
ty of elements and attributes means additional choices at each encode/decod=
e boundary, and guaranteed ambiguity.



To continue=
 the argument made by mark Nottingham and Tim Bray, having to choose betwee=
n attributes and elements at each point imposes the same overhead at a diff=
erent layer than having to choose between xml and json.



Yes, this natural mapping does not hold true=
 for C, because C doesn't have a native dictionary/hashtag data structu=
re. C doesn't make XML or anything else easy either, but C programmers =
are used to that.


On Mon, Apr 23, 2012 at 10:56 PM, Paul E. Jo=
nes <paulej@packetizer.com> wrote:

Michael,




> =C2=A0From a programming standpoint, JSON is just easier to deal with.=
 Consider

> these two links:

>

> h=
ttp://php.net/manual/en/book.json.php

>

> ht=
tp://php.net/manual/en/book.xml.php

>

> and tell me which you'd rather deal with. It's not huge, but i=
t's not

> nothing either.




To be fair, this works well partly because of the language. =C2=A0Wor=
ks even

better in JavaScript. =C2=A0It would work less well in C. =C2=A0Here's =
just one

example:

http://=
www.digip.org/jansson/doc/2.3/



JSON bits do not map perfectly to C. =C2=A0I thought C++ might be simpler, =
but

the first library I grabbed had library documentation that was 224 pages
long (libjson).



When I process simple XML like that from WebFinger, I tend to use a parser<=
br>
that just steps through each node in order. =C2=A0I don't need to decod=
e the

whole "document" in memory and reference pieces and parts of it: =
one pass

over it and I grab what I need. =C2=A0It's very simple to process the X=
ML output

from WebFinger that way.



Paul






_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--20cf300fab73128cb404be6f736f--

From stpeter@stpeter.im  Tue Apr 24 09:53:08 2012
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 554C921F879F for ; Tue, 24 Apr 2012 09:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.609
X-Spam-Level: 
X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovp0+x22Wt0p for ; Tue, 24 Apr 2012 09:53:06 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BA27421F879E for ; Tue, 24 Apr 2012 09:53:06 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1455940058; Tue, 24 Apr 2012 11:07:38 -0600 (MDT)
Message-ID: <4F96DA70.4020108@stpeter.im>
Date: Tue, 24 Apr 2012 10:53:04 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Eran Hammer 
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net>
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 16:53:08 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/24/12 10:20 AM, Eran Hammer wrote:
> We've been kicking this can of silliness for months now because
> one person refuses to move on even in the face of otherwise
> unanimous consensus from the group.

Hi Eran,

Cans of silliness aside, I'd like to make a brief meta point: we don't
vote. So consensus is not a matter of counting noses, it is a matter
of addressing valid technical issues that people raise. I shall
re-read this thread and related earlier threads to see if the issues
raised by Michael Thomas have been answered, but if there are open
issues then we need to address them. Now, it might be that he hasn't
accepted the answers provided, in which case he might be "in the
rough". That's the chairs' call. But it's not necessarily a simple
matter of saying that one person disagrees therefore we can move on.
However, I think you know that anyway. :)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+W2nAACgkQNL8k5A2w/vxQyACgyCDPDrxbFKLcntB2uu8TF+Zu
F24AoIfDHW+Z88nE16Wt+iLn+Dqch50l
=5WMm
-----END PGP SIGNATURE-----

From derek@ihtfp.com  Tue Apr 24 10:11:26 2012
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 8CAFC21F8621 for ; Tue, 24 Apr 2012 10:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.912
X-Spam-Level: 
X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y89RLCToOBya for ; Tue, 24 Apr 2012 10:11:21 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id A1D7121E8095 for ; Tue, 24 Apr 2012 10:11:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C2D712602A6; Tue, 24 Apr 2012 13:11:20 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 05511-08; Tue, 24 Apr 2012 13:11:19 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id C82502602A5; Tue, 24 Apr 2012 13:11:19 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3OHBDcd016757; Tue, 24 Apr 2012 13:11:13 -0400
From: Derek Atkins 
To: Eran Hammer 
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net>
Date: Tue, 24 Apr 2012 13:11:10 -0400
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net> (Eran Hammer's message of "Tue, 24 Apr 2012 16:20:46 +0000")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 17:11:26 -0000

Eran Hammer  writes:

> We've been kicking this can of silliness for months now because one
> person refuses to move on even in the face of otherwise unanimous
> consensus from the group.
>
> Chairs - Please take this ridiculous and never ending thread off list
> and resolve it once and for all.

Sure, I'll gladly stop the thread when the document is updated to
actually mention all threats that someone has considered and brought to
the group's attention.  That *is* the point of a threats document, after
all.

In a threats document nothing should be implicit or assumed -- the
reader does not have the advantage of our group's knowledge of the space
or operational guidance.  As a result, everything should be explicitly
stated.

Every threat that is brought to the attention of this gorup should be
mentioned, explicitly, even if it's only a single sentence as part of a
paragraph of "threats that fall outside the aforementioned assumptions"
or "threats that have a simple workaround".

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From phil.hunt@oracle.com  Tue Apr 24 10:26:51 2012
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 7D15D21F8826 for ; Tue, 24 Apr 2012 10:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.175
X-Spam-Level: 
X-Spam-Status: No, score=-10.175 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3alLouRHpaG for ; Tue, 24 Apr 2012 10:26:50 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCED21F8652 for ; Tue, 24 Apr 2012 10:26:50 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3OHQlFZ004734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Apr 2012 17:26:48 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q3OHQkXC005839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 17:26:47 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3OHQkjN027094; Tue, 24 Apr 2012 12:26:46 -0500
Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Apr 2012 10:26:46 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Phil Hunt 
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net>
Date: Tue, 24 Apr 2012 10:26:46 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <580607FC-28EC-4BBA-8CBA-C63D2FA52C8E@oracle.com>
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net>
To: Eran Hammer 
X-Mailer: Apple Mail (2.1257)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 17:26:51 -0000

Folks this is a "scoping" debate.  Because this document is a brand new =
type of specification, I can see why there is some confusion.

First, I want to point out the concerns Michael Thomas are making are =
*valid*.

**However**  Editorially I feel strongly the comments fall outside the =
intended scope and purpose for this document. This document is about =
threats specifically related to the OAuth protocol.  It's intent is to =
go beyond security considerations to give implementers a feel for the =
issues the group has considered specific to the protocol.

Michael's comments are directed at general trusted computing platform. =
And while I agree they are valid, they don't fit in this document. At no =
time did the OAuth WG set out to solve or debate trusted computing =
platform issues. It is simply not within the charter of the WG.

Michael feels the premise for the document is "borked" because his =
comments are not included.  However, there are those of us that feel the =
document instead needs to be sharply edited back to focus even tighter =
on OAuth specific issues.

As for "consensus" there seems to be two issues/questions at hand:

1. Do we go back and extend the document scope to general trusted =
computing platforms issues?=20

2. Is the document correct for the content that it has now?

I suspect there is strong consensus for number 2.=20

I suspect there is quite a lot of debate about number 1. For me, I will =
push very hard to cut the document in half (the opposite).  My worry is =
the document is too long, and many are already not reading it because it =
is only an Informational document.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-04-24, at 9:20 AM, Eran Hammer wrote:

> We've been kicking this can of silliness for months now because one =
person refuses to move on even in the face of otherwise unanimous =
consensus from the group.
>=20
> Chairs - Please take this ridiculous and never ending thread off list =
and resolve it once and for all.
>=20
> EH
>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf
>> Of Phil Hunt
>> Sent: Tuesday, April 24, 2012 7:59 AM
>> To: Michael Thomas
>> Cc: Barry Leiba; oauth@ietf.org; oauth-bounces@ietf.org
>> Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-
>> threatmodel
>>=20
>> Are we at this stage re-opening the entire document? I thought we =
were
>> responding only to specific shepherd text edits.
>>=20
>> Phil
>>=20
>> On 2012-04-24, at 6:24, Michael Thomas  wrote:
>>=20
>>> On 04/24/2012 01:17 AM, Mark Mcgloin wrote:
>>>> Hi Thomas
>>>>=20
>>>> Your additional text is already covered in a countermeasure for
>>>> section 4.1.4.  In addition, section 4.1.4.4 states the assumption
>>>> that the auth server can't protect against a user installing a
>>>> malicious client
>>>>=20
>>>=20
>>> The more I read this draft, the more borked I think its base
>>> assumptions are. The client *is* one of the main threats. Full stop. =
A
>>> threat document should not be asking the adversary to play nice. =
Yet,
>>> 4.1.4 bullets 1 and
>>> 3 are doing exactly that again. If those are countermeasures, then =
so
>>> is visualizing world peace.
>>>=20
>>> As for bullet two, it doesn't mention revocation, and I prefer =
Barry's
>>> section generally. I can't find a section 4.1.4.4
>>>=20
>>> Mike
>>> _______________________________________________
>>> 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


From mike@mtcc.com  Tue Apr 24 10:37:14 2012
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 0605421F8867 for ; Tue, 24 Apr 2012 10:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RjlQp3Jb052 for ; Tue, 24 Apr 2012 10:37:13 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 1226B21F8861 for ; Tue, 24 Apr 2012 10:37:12 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3OHb9Dd011135 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 10:37:09 -0700
Message-ID: <4F96E4C5.7070601@mtcc.com>
Date: Tue, 24 Apr 2012 10:37:09 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Phil Hunt 
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net> <580607FC-28EC-4BBA-8CBA-C63D2FA52C8E@oracle.com>
In-Reply-To: <580607FC-28EC-4BBA-8CBA-C63D2FA52C8E@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=829; t=1335289030; x=1336153030; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20Shepherd=20review=20of=20d raft-ietf-oauth-v2-threatmodel |Sender:=20 |To:=20Phil=20Hunt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=27/4JPFgtFq3rmXECUTw7d/7vxv7tBje+YW7kXbrpxY=; b=nM1sFBSLsm3M0yNwr442czNTylJFAIdnsz6SW948tMYANiHwHtxa4sMHQo SnA+OKbMp5qy9YbpCcNO2+V/kFuCiBrkm1hBKYQ1pHb/BH8riJt36uW+2/4n dVV/RT6Lf5yFvZ1wK3cxSp9IdkM8HQJPAIE4qb/ZGP01ywCICiENk=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 17:37:14 -0000

On 04/24/2012 10:26 AM, Phil Hunt wrote:
> Michael feels the premise for the document is "borked" because his comments are not included.  However, there are those of us that feel the document instead needs to be sharply edited back to focus even tighter on OAuth specific issues.

Actually, my last call comments were for two different things:

1) remove mitigation bullets that are either wrong, ineffective,
     or smarmy platitudes (cf 'borked').
2) make perfectly clear that embedded webviews and native clients
     which widely use oauth today do not protect users from rogue clients
     gaining access to their credentials. My bullet added to Barry's edits
     on this point was mainly to reinforce that authentication servers
     have a part to play too.

I would think you'd be happy for #1 :)

Mike


From eran@hueniverse.com  Tue Apr 24 11:05:04 2012
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 4236711E808F for ; Tue, 24 Apr 2012 11:05:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level: 
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE-HHapgy674 for ; Tue, 24 Apr 2012 11:05:03 -0700 (PDT)
Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8D44B11E80C1 for ; Tue, 24 Apr 2012 11:05:03 -0700 (PDT)
Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id 1u531j0070CJzpC01u53jx; Tue, 24 Apr 2012 11:05:03 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Tue, 24 Apr 2012 11:05:02 -0700
From: Eran Hammer 
To: Derek Atkins 
Thread-Topic: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
Thread-Index: AQHNIj0+r7KmwuXA4kSoc9MS46QExJaqQQHw
Date: Tue, 24 Apr 2012 18:05:02 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC664@P3PWEX2MB008.ex2.secureserver.net>
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 18:05:04 -0000

There is a lot of history on this thread.

At the heart of it is a request from a working group member that the specif=
ication makes it clear that OAuth does not protect against malware and viru=
ses, or other malicious software installed on the user device. During the f=
irst (or second, I can't recall) run of this debate, the chair *did* make a=
 consensus call that the WG did not feel this was an OAuth specific threat.=
 The chair's proposed resolution at the time was clearly too vague to close=
 the issue and hence we are still arguing about it.

Adding the requested threat will make the document look less credible for s=
tating the obvious. I do not agree that any threat mentioned should be list=
ed. At some point, and we're almost there, you lose the forest for the tree=
s.

And BTW, as a response to Michael's original comment, I have requested that=
 the threat of earthquakes will also be listed under UX considerations to p=
revent a user from clicking 'Approve' during an earthquake if it is too clo=
se to the 'Deny' button. Is my threat, which is clearly valid (no matter ho=
w unlikely), going to be added as well? Please don't, but I hope you see my=
 point here. Many bad things can happen to you while using OAuth.

I don't care how this is resolved. At this point I don't mind the threat be=
ing added just to close the issue.

EH

> -----Original Message-----
> From: Derek Atkins [mailto:derek@ihtfp.com]
> Sent: Tuesday, April 24, 2012 10:11 AM
> To: Eran Hammer
> Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-
> threatmodel
>=20
> Eran Hammer  writes:
>=20
> > We've been kicking this can of silliness for months now because one
> > person refuses to move on even in the face of otherwise unanimous
> > consensus from the group.
> >
> > Chairs - Please take this ridiculous and never ending thread off list
> > and resolve it once and for all.
>=20
> Sure, I'll gladly stop the thread when the document is updated to actuall=
y
> mention all threats that someone has considered and brought to the group'=
s
> attention.  That *is* the point of a threats document, after all.
>=20
> In a threats document nothing should be implicit or assumed -- the reader
> does not have the advantage of our group's knowledge of the space or
> operational guidance.  As a result, everything should be explicitly state=
d.
>=20
> Every threat that is brought to the attention of this gorup should be
> mentioned, explicitly, even if it's only a single sentence as part of a p=
aragraph
> of "threats that fall outside the aforementioned assumptions"
> or "threats that have a simple workaround".
>=20
> -derek
>=20
> --
>        Derek Atkins                 617-623-3745
>        derek@ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant

From eran@hueniverse.com  Tue Apr 24 11:05:56 2012
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 E832021F86FD for ; Tue, 24 Apr 2012 11:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level: 
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dI2ibuHSWThx for ; Tue, 24 Apr 2012 11:05:56 -0700 (PDT)
Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 13B4621F8702 for ; Tue, 24 Apr 2012 11:05:56 -0700 (PDT)
Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id 1u5v1j0080CJzpC01u5vnm; Tue, 24 Apr 2012 11:05:55 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Tue, 24 Apr 2012 11:05:55 -0700
From: Eran Hammer 
To: Peter Saint-Andre 
Thread-Topic: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
Thread-Index: AQHNIfK7r7KmwuXA4kSoc9MS46QExJaqbLCAgAAaSoD//6DfUIAAfwgA//+e4SA=
Date: Tue, 24 Apr 2012 18:05:55 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC677@P3PWEX2MB008.ex2.secureserver.net>
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net> <4F96DA70.4020108@stpeter.im>
In-Reply-To: <4F96DA70.4020108@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.74.213.174]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 18:05:57 -0000

QmVycnkgZGlkIG1ha2UgYSBjb25zZW5zdXMgY2FsbCB3aGVuIHRoaXMgd2FzIG9yaWdpbmFsbHkg
cmFpc2VkLg0KDQpFSA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBl
dGVyIFNhaW50LUFuZHJlIFttYWlsdG86c3RwZXRlckBzdHBldGVyLmltXQ0KPiBTZW50OiBUdWVz
ZGF5LCBBcHJpbCAyNCwgMjAxMiA5OjUzIEFNDQo+IFRvOiBFcmFuIEhhbW1lcg0KPiBDYzogb2F1
dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog
W09BVVRILVdHXSBTaGVwaGVyZCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC12Mi0NCj4gdGhy
ZWF0bW9kZWwNCj4gDQo+IC0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0NCj4gSGFz
aDogU0hBMQ0KPiANCj4gT24gNC8yNC8xMiAxMDoyMCBBTSwgRXJhbiBIYW1tZXIgd3JvdGU6DQo+
ID4gV2UndmUgYmVlbiBraWNraW5nIHRoaXMgY2FuIG9mIHNpbGxpbmVzcyBmb3IgbW9udGhzIG5v
dyBiZWNhdXNlIG9uZQ0KPiA+IHBlcnNvbiByZWZ1c2VzIHRvIG1vdmUgb24gZXZlbiBpbiB0aGUg
ZmFjZSBvZiBvdGhlcndpc2UgdW5hbmltb3VzDQo+ID4gY29uc2Vuc3VzIGZyb20gdGhlIGdyb3Vw
Lg0KPiANCj4gSGkgRXJhbiwNCj4gDQo+IENhbnMgb2Ygc2lsbGluZXNzIGFzaWRlLCBJJ2QgbGlr
ZSB0byBtYWtlIGEgYnJpZWYgbWV0YSBwb2ludDogd2UgZG9uJ3Qgdm90ZS4gU28NCj4gY29uc2Vu
c3VzIGlzIG5vdCBhIG1hdHRlciBvZiBjb3VudGluZyBub3NlcywgaXQgaXMgYSBtYXR0ZXIgb2Yg
YWRkcmVzc2luZyB2YWxpZA0KPiB0ZWNobmljYWwgaXNzdWVzIHRoYXQgcGVvcGxlIHJhaXNlLiBJ
IHNoYWxsIHJlLXJlYWQgdGhpcyB0aHJlYWQgYW5kIHJlbGF0ZWQNCj4gZWFybGllciB0aHJlYWRz
IHRvIHNlZSBpZiB0aGUgaXNzdWVzIHJhaXNlZCBieSBNaWNoYWVsIFRob21hcyBoYXZlIGJlZW4N
Cj4gYW5zd2VyZWQsIGJ1dCBpZiB0aGVyZSBhcmUgb3BlbiBpc3N1ZXMgdGhlbiB3ZSBuZWVkIHRv
IGFkZHJlc3MgdGhlbS4gTm93LA0KPiBpdCBtaWdodCBiZSB0aGF0IGhlIGhhc24ndCBhY2NlcHRl
ZCB0aGUgYW5zd2VycyBwcm92aWRlZCwgaW4gd2hpY2ggY2FzZSBoZQ0KPiBtaWdodCBiZSAiaW4g
dGhlIHJvdWdoIi4gVGhhdCdzIHRoZSBjaGFpcnMnIGNhbGwuIEJ1dCBpdCdzIG5vdCBuZWNlc3Nh
cmlseSBhIHNpbXBsZQ0KPiBtYXR0ZXIgb2Ygc2F5aW5nIHRoYXQgb25lIHBlcnNvbiBkaXNhZ3Jl
ZXMgdGhlcmVmb3JlIHdlIGNhbiBtb3ZlIG9uLg0KPiBIb3dldmVyLCBJIHRoaW5rIHlvdSBrbm93
IHRoYXQgYW55d2F5LiA6KQ0KPiANCj4gUGV0ZXINCj4gDQo+IC0gLS0NCj4gUGV0ZXIgU2FpbnQt
QW5kcmUNCj4gaHR0cHM6Ly9zdHBldGVyLmltLw0KPiANCj4gDQo+IC0tLS0tQkVHSU4gUEdQIFNJ
R05BVFVSRS0tLS0tDQo+IFZlcnNpb246IEdudVBHL01hY0dQRzIgdjIuMC4xOCAoRGFyd2luKQ0K
PiBDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwubW96
ZGV2Lm9yZy8NCj4gDQo+IGlFWUVBUkVDQUFZRkFrK1cybkFBQ2drUU5MOGs1QTJ3L3Z4UXlBQ2d5
Q0RQRHJ4YkZLTGNudEIydXU4VEYNCj4gK1p1DQo+IEYyNEFvSWZESFcrWjg4bkUxNld0K2lMbitE
cWNoNTBsDQo+ID01V01tDQo+IC0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K

From stpeter@stpeter.im  Tue Apr 24 11:10:10 2012
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 6F78621F8750 for ; Tue, 24 Apr 2012 11:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.609
X-Spam-Level: 
X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pu3SchR3jY8 for ; Tue, 24 Apr 2012 11:10:10 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ECD4D21F87A7 for ; Tue, 24 Apr 2012 11:10:09 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8538940058; Tue, 24 Apr 2012 12:24:42 -0600 (MDT)
Message-ID: <4F96EC80.40902@stpeter.im>
Date: Tue, 24 Apr 2012 12:10:08 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Eran Hammer 
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net> <4F96DA70.4020108@stpeter.im> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC677@P3PWEX2MB008.ex2.secureserver.net>
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC677@P3PWEX2MB008.ex2.secureserver.net>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 18:10:10 -0000

Indeed you are right, I'd forgotten about that.

On 4/24/12 12:05 PM, Eran Hammer wrote:
> Barry did make a consensus call when this was originally raised.
> 
> EH
> 
>> -----Original Message-----
>> From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
>> Sent: Tuesday, April 24, 2012 9:53 AM
>> To: Eran Hammer
>> Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-
>> threatmodel
>>
> On 4/24/12 10:20 AM, Eran Hammer wrote:
>>>> We've been kicking this can of silliness for months now because one
>>>> person refuses to move on even in the face of otherwise unanimous
>>>> consensus from the group.
> 
> Hi Eran,
> 
> Cans of silliness aside, I'd like to make a brief meta point: we don't vote. So
> consensus is not a matter of counting noses, it is a matter of addressing valid
> technical issues that people raise. I shall re-read this thread and related
> earlier threads to see if the issues raised by Michael Thomas have been
> answered, but if there are open issues then we need to address them. Now,
> it might be that he hasn't accepted the answers provided, in which case he
> might be "in the rough". That's the chairs' call. But it's not necessarily a simple
> matter of saying that one person disagrees therefore we can move on.
> However, I think you know that anyway. :)
> 
> Peter
>

From mike@mtcc.com  Tue Apr 24 11:17:52 2012
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 3B5D021F881B for ; Tue, 24 Apr 2012 11:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level: 
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NywGHuLC44ue for ; Tue, 24 Apr 2012 11:17:51 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1D421F854F for ; Tue, 24 Apr 2012 11:17:51 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3OIHn2f027175 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 11:17:49 -0700
Message-ID: <4F96EE4D.6070805@mtcc.com>
Date: Tue, 24 Apr 2012 11:17:49 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Peter Saint-Andre 
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net> <4F96DA70.4020108@stpeter.im> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC677@P3PWEX2MB008.ex2.secureserver.net> <4F96EC80.40902@stpeter.im>
In-Reply-To: <4F96EC80.40902@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1914; t=1335291470; x=1336155470; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20Shepherd=20review=20of=20d raft-ietf-oauth-v2-threatmodel |Sender:=20 |To:=20Peter=20Saint-Andre=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=rP5aN5PKoUzJZsL1tAYIS0vFFzcf095GyskAd1eJbrc=; b=ZcdsTTyGe6l1fzogJJ01nxAKMY45CGVw1Tzfz6wBsP6le2AwoiHmAvmXpF QpL4zNXFjBqqc0P0+G7CPRPPUx6xMPAviCknV39iQN33hKK4A04GdmTYMAMi ZvrPAtmWKeCS8InfwNzRej1aBmKzcPnYKj9znOA3gPtBynJJ4iFpA=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Tue, 24 Apr 2012 18:17:52 -0000

On 04/24/2012 11:10 AM, Peter Saint-Andre wrote:
> Indeed you are right, I'd forgotten about that.

The original conclusion was to let oauth progress and move
the discussion to -threats. I brought it up with -threats and
again in last call and got no closure that I recall. Barry's
shepherd review was in response to me bringing up that my
issues had not been resolved in last call.

Mike

>
> On 4/24/12 12:05 PM, Eran Hammer wrote:
>> Barry did make a consensus call when this was originally raised.
>>
>> EH
>>
>>> -----Original Message-----
>>> From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
>>> Sent: Tuesday, April 24, 2012 9:53 AM
>>> To: Eran Hammer
>>> Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-
>>> threatmodel
>>>
>> On 4/24/12 10:20 AM, Eran Hammer wrote:
>>>>> We've been kicking this can of silliness for months now because one
>>>>> person refuses to move on even in the face of otherwise unanimous
>>>>> consensus from the group.
>> Hi Eran,
>>
>> Cans of silliness aside, I'd like to make a brief meta point: we don't vote. So
>> consensus is not a matter of counting noses, it is a matter of addressing valid
>> technical issues that people raise. I shall re-read this thread and related
>> earlier threads to see if the issues raised by Michael Thomas have been
>> answered, but if there are open issues then we need to address them. Now,
>> it might be that he hasn't accepted the answers provided, in which case he
>> might be "in the rough". That's the chairs' call. But it's not necessarily a simple
>> matter of saying that one person disagrees therefore we can move on.
>> However, I think you know that anyway. :)
>>
>> Peter
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From mike@mtcc.com  Tue Apr 24 14:00:44 2012
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 AE77511E80AB; Tue, 24 Apr 2012 14:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.261
X-Spam-Level: 
X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j-v1RwVq2P1; Tue, 24 Apr 2012 14:00:44 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 3272A11E8074; Tue, 24 Apr 2012 14:00:44 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q3OL0gj0027071 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 14:00:43 -0700
Message-ID: <4F97147A.7020503@mtcc.com>
Date: Tue, 24 Apr 2012 14:00:42 -0700
From: Michael Thomas 
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Derek Atkins 
References: <423611CD-8496-4F89-8994-3F837582EB21@gmx.net> <4F8852D0.4020404@cs.tcd.ie> <9452079D1A51524AA5749AD23E0039280EFE8D@exch-mbx901.corp.cloudmark.com>  <9452079D1A51524AA5749AD23E0039280FACC3@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366490B2A@TK5EX14MBXC284.redmond.corp.microsoft.com> <091401cd1ea3$e159be70$a40d3b50$@packetizer.com>  <091901cd1eb0$167a8ce0$436fa6a0$@packetizer.com>  <4F917545.5080103@mtcc.com>  <4F9573D6.9080603@mtcc.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2331; t=1335301243; x=1336165243; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20[apps-discuss]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Derek=20Atkins=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ZRm2iFlcuB1ZSWNJCMNNNFq4umlLCvS4RWBuA48Ctms=; b=Gx9lVvhBCoBxrCpKx7obJhfJFwGbz7r+/VQ03FOmDD+wVfXRNL7Xek1ic2 m2cFOtSuDtOtkYZuIIuPIrxtE7vguToG5Mc+6ipUxoK5OHPx8m0Z6uqzkUhY fSJa1MCjdPB5OwU/sJxIVtC49/iUSiedsi9cNbraNkGOm4hHS30ms=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
Cc: 'Tim Bray' , oauth@ietf.org, 'Apps Discuss' 
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
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: Tue, 24 Apr 2012 21:00:44 -0000

On 04/23/2012 09:55 AM, Derek Atkins wrote:
> Michael Thomas  writes:
>
>> Derek Atkins wrote:
>>> Michael Thomas  writes:
>>>
>>>> Why not MUST ASN.1 while you're at it? JSON has won in case
>>>> you'all haven't noticed it.
>>> Well, now that you mention it...   ;-)
>>>
>>> But seriously, we're basing this work on an RFC that was just release
>>> six months ago and it requires XML.  Why be so quick to drop something
>>> we just published half a year ago?  So maybe in 6 months we drop JSON
>>> and add the next big thing?  Come on, Mike.
>>>
>>> I agree, we should definitely support JSON.  But I also think we should
>>> support XML.  The client can do what it wants, which is where want the
>>> light weight implementation.
>> I think you're probably misunderstanding me. I'm (I believe) with Tim
>> in saying "pick one". Just one. For clients and servers. And I'm only
> No, I'm not misunderstanding you, I know exactly what you are arguing
> for.  And I'm agreeing with you that we must support JSON.  However, I
> disagree that we should drop XML, especially considering 6415 requires
> XML and it was just released 6 months ago.
>
> I'm also saying that this is only a server-side requirement to support
> both.  The client can choose to support only one based on its own
> requirements.  If you already have an XML-based client, why force them
> to add JSON support?  Similarly, if you already have a JSON-based
> client, why force them to add XML support?
>
> If you're writing a client, you can ignore XML and only play with JSON.
>

Derek -- I think that the modern reality is that most things can
support both without much problem from a code footprint and
library availability standpoint,  both client and server. But that
misses a larger point of whether we _should_ just because we
_can_. There is a cost to maintaining two different encoding/
decoding both on the implementation side, as well as the
specification (and the debugging thereof) side. So my feeling
is that "chose one" should *always* be a SHOULD in the way
that Stephen outlined as well. If that means choosing XML
mainly for historical reasons, that's still better than trying to
placate both sides or "facilitating the transition" or any other
reason on offer.

Mike

From mark.mcgloin@ie.ibm.com  Wed Apr 25 02:06:41 2012
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 8953D21F87AE for ; Wed, 25 Apr 2012 02:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1O43suvzA04 for ; Wed, 25 Apr 2012 02:06:38 -0700 (PDT)
Received: from e06smtp18.uk.ibm.com (e06smtp18.uk.ibm.com [195.75.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id 64C9021F87A2 for ; Wed, 25 Apr 2012 02:06:38 -0700 (PDT)
Received: from /spool/local by e06smtp18.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Wed, 25 Apr 2012 10:06:36 +0100
Received: from d06nrmr1707.portsmouth.uk.ibm.com (9.149.39.225) by e06smtp18.uk.ibm.com (192.168.101.148) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Wed, 25 Apr 2012 10:06:33 +0100
Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3P96WHF1319020; Wed, 25 Apr 2012 10:06:32 +0100
Received: from d06av10.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3P93Zpe006350; Wed, 25 Apr 2012 05:03:36 -0400
Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3P93Z9H006347; Wed, 25 Apr 2012 05:03:35 -0400
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC677@P3PWEX2MB008.ex2.secureserver.net>
References: 	<4F8DE789.4030704@mtcc.com> 	<4F957EA7.3060004@mtcc.com> 	<4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com>	<0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net> <4F96DA70.4020108@stpeter.im> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC677@P3PWEX2MB008.ex2.secureserver.net>
X-KeepSent: C25E2154:A28FCD53-802579EB:0031C48A; type=4; name=$KeepSent
To: Eran Hammer 
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: 
From: Mark Mcgloin 
Date: Wed, 25 Apr 2012 10:06:25 +0100
X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 25/04/2012 10:06:26
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
x-cbid: 12042509-6892-0000-0000-000001A8AD72
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Wed, 25 Apr 2012 09:06:42 -0000

This topic should not have been raised again with this mailing list as we
did reach a consensus before. What happened was that Barry sent a targeted
email to some people, including Michael Thomas, regarding some additional
wording as part of his shepard review. Michael inadvertently replied to
this email list

If everyone could avoid replying to this thread, we can resolve our
differences with the smaller mail group


thanks
Mark

oauth-bounces@ietf.org wrote on 24/04/2012 19:05:55:

> From:
>
> Eran Hammer 
>
> To:
>
> Peter Saint-Andre 
>
> Cc:
>
> "oauth-chairs@tools.ietf.org" ,
> "oauth@ietf.org" 
>
> Date:
>
> 24/04/2012 19:06
>
> Subject:
>
> Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
>
> Sent by:
>
> oauth-bounces@ietf.org
>
> Berry did make a consensus call when this was originally raised.
>
> EH
>
> > -----Original Message-----
> > From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
> > Sent: Tuesday, April 24, 2012 9:53 AM
> > To: Eran Hammer
> > Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org
> > Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-
> > threatmodel
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 4/24/12 10:20 AM, Eran Hammer wrote:
> > > We've been kicking this can of silliness for months now because one
> > > person refuses to move on even in the face of otherwise unanimous
> > > consensus from the group.
> >
> > Hi Eran,
> >
> > Cans of silliness aside, I'd like to make a brief meta point: we
> don't vote. So
> > consensus is not a matter of counting noses, it is a matter of
> addressing valid
> > technical issues that people raise. I shall re-read this thread and
related
> > earlier threads to see if the issues raised by Michael Thomas have been
> > answered, but if there are open issues then we need to address them.
Now,
> > it might be that he hasn't accepted the answers provided, in which case
he
> > might be "in the rough". That's the chairs' call. But it's not
> necessarily a simple
> > matter of saying that one person disagrees therefore we can move on.
> > However, I think you know that anyway. :)
> >
> > Peter
> >
> > - --
> > Peter Saint-Andre
> > https://stpeter.im/
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAk+W2nAACgkQNL8k5A2w/vxQyACgyCDPDrxbFKLcntB2uu8TF
> > +Zu
> > F24AoIfDHW+Z88nE16Wt+iLn+Dqch50l
> > =5WMm
> > -----END PGP SIGNATURE-----
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


From julian.reschke@gmx.de  Wed Apr 25 05:45:58 2012
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 4AA5121F855A for ; Wed, 25 Apr 2012 05:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.84
X-Spam-Level: 
X-Spam-Status: No, score=-101.84 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2hOrUftCaZc for ; Wed, 25 Apr 2012 05:45:57 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1B96921F8608 for ; Wed, 25 Apr 2012 05:45:56 -0700 (PDT)
Received: (qmail invoked by alias); 25 Apr 2012 12:45:55 -0000
Received: from unknown (EHLO [42.1.3.81]) [192.147.117.12] by mail.gmx.net (mp027) with SMTP; 25 Apr 2012 14:45:55 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+jqhIM/nejLueqGCTUNXegf3NPZzI7wXZ1EzsvWs 3dMYTkSDvugp5x
Message-ID: <4F97F202.6070100@gmx.de>
Date: Wed, 25 Apr 2012 14:45:54 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: Eran Hammer 
References: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFB23D@P3PWEX2MB008.ex2.secureserver.net>
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFB23D@P3PWEX2MB008.ex2.secureserver.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "oauth@ietf.org WG \(oauth@ietf.org\)" 
Subject: Re: [OAUTH-WG] OAuth ABNF
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: Wed, 25 Apr 2012 12:45:58 -0000

On 2012-04-23 23:19, Eran Hammer wrote:
> During the IESG review of draft-ietf-oauth-v2, Sean Turner raised the
> following DISCUSS item (meaning, the specification is blocked until this
> is resolved):
>
>  > 0) General: I found the lack of ABNF somewhat disconcerting in that
>
>  > implementers would have to hunt through the spec to figure out all the
>
>  > values of a given field. For example grant_type has different values
> based
>
>  > on the different kind of access_token requests - four to be more
> precise -
>
>  > but there's no ABNF for the field. There are many examples of
>
>  > this. It would greatly aid implementers if a) the ABNF for all fields
>
>  > were included in the draft and b) all the ABNF was collected in one
> place. I
>
>  > had individual discusses for each field that had missing ABNF, but it
> was
>
>  > getting out of hand so I'm just going to do this one general discuss
> on this
>
>  > topic.
>
> I don’t have the time to prepare such text. Can someone volunteer to
> submit this text to the WG for review?

Putting values in the ABNF makes only sense if and only of the set of 
values is hardwired, so there's no extension point. Otherwise it's 
misleading, because it will lead to fragile parser implementations.

WRT collected ABNF: this can be generated automatically, you may want to 
have a look at 
.

Best regards, Julian

From bcampbell@pingidentity.com  Wed Apr 25 07:04:28 2012
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 DD54821F86E0 for ; Wed, 25 Apr 2012 07:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.94
X-Spam-Level: 
X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLJDHEBxwvhD for ; Wed, 25 Apr 2012 07:04:27 -0700 (PDT)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 373A121F86DA for ; Wed, 25 Apr 2012 07:04:27 -0700 (PDT)
Received: from mail-vb0-f54.google.com ([209.85.212.54]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKT5gEag6+BO/pIv+FOLKZxsVwIh2dl9na@postini.com; Wed, 25 Apr 2012 07:04:27 PDT
Received: by vbmv11 with SMTP id v11so110496vbm.27 for ; Wed, 25 Apr 2012 07:04:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=Qfk8QrhOUORtAsYdhhgIRK13tcyvwld2U0eiY9KAZio=; b=KDUiwZeN+jdPIJTTbAu01QBmM+9cKFJZayDMM5V5+JiPDBK8rW0hU9WcLgHkuuTfE4 tFyFB/De7U3DQXq2ZiXNrbnt95kh8m91CoxnYwyfREeegx8y/d4TVFGvMvHmHS2iECkg jFXVjHe1adm8mTDN9jtYYPFLqA/UDJTxJMCfc6cEax/TWtsf4TZYeaZD7ZQCVzSmHohe qEUZ6l5UvOAh+8uOZN2T/Ksvq9z7OZmw1QSjmkjxfYVmmckicKcxVFCj8xZWIDGHodw8 gvGIJQwt6wlBOcjLkWoH5ZeU9ubv/gEdy6pVylxJccusN5Na/ndX6xs5zxVMsZjDRHvu 7MsA==
Received: by 10.52.65.69 with SMTP id v5mr2266542vds.14.1335362665417; Wed, 25 Apr 2012 07:04:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.38.104 with HTTP; Wed, 25 Apr 2012 07:03:55 -0700 (PDT)
In-Reply-To: 
References: 
From: Brian Campbell 
Date: Wed, 25 Apr 2012 08:03:55 -0600
Message-ID: 
To: oauth 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkRPr411ExvL6pAKU8gyf+3Apuw4QF9HNfa56hSJa7e3pFRaQYZaAKsXrV4v104wp0JVtOx
Subject: Re: [OAUTH-WG] double normative? (draft-ietf-oauth-assertions WGLC comment V)
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: Wed, 25 Apr 2012 14:04:29 -0000

I just noticed that there is a similar situation in =A74.1* and 4.2**
where there's a MUST before defining the HTTP parameters but some of
the individual parameters are marked as OPTIONAL.

The MUST should probably be dropped.

* http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.1
** http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.2



On Mon, Apr 23, 2012 at 3:26 PM, Brian Campbell
 wrote:
> Sections 6.1, 6.2, 6.3 and 6.4 of
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 are all similar=
 in
> that they have a paragraph at the top that ends with, "The following form=
at
> and processing rules SHOULD be applied:" followed by a bullet list of
> specific rules. However some of the individual bullets themselves have
> normative language including several that have a MUST. On rereading the
> draft today, I found this to be a little confusing. I mean, what does it
> mean to say that you SHOULD MUST do something? At a minimum, it seems lik=
e
> kind of bad form. I'm thinking that the lead in text before each list sho=
uld
> just say something like "The following format and processing rules are to=
 be
> applied:" to avoid any potential logical conflict between the normative
> terms. But depending on how the previous text was interpreted, that could=
 be
> considered a breaking change? That might be okay though as this is just a=
n
> abstract specification. Any thoughts?

From derek@ihtfp.com  Wed Apr 25 08:38:19 2012
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 5128221F87B4 for ; Wed, 25 Apr 2012 08:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.419
X-Spam-Level: 
X-Spam-Status: No, score=-101.419 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_BACKHAIR_42=1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pgJh5DSzeS0 for ; Wed, 25 Apr 2012 08:38:18 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCC121F87B0 for ; Wed, 25 Apr 2012 08:38:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 628C82602A6; Wed, 25 Apr 2012 11:38:13 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 12044-02; Wed, 25 Apr 2012 11:38:12 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 586512601D8; Wed, 25 Apr 2012 11:38:12 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3PFc9x2003861; Wed, 25 Apr 2012 11:38:09 -0400
From: Derek Atkins 
To: Eran Hammer 
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net>  <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC664@P3PWEX2MB008.ex2.secureserver.net>
Date: Wed, 25 Apr 2012 11:38:07 -0400
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC664@P3PWEX2MB008.ex2.secureserver.net> (Eran Hammer's message of "Tue, 24 Apr 2012 18:05:02 +0000")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Wed, 25 Apr 2012 15:38:19 -0000

Eran Hammer  writes:

> There is a lot of history on this thread.

I know.  I have read it all.  Frankly, I feel that Michael was treated
poorly by the members of this group.

> At the heart of it is a request from a working group member that the
> specification makes it clear that OAuth does not protect against
> malware and viruses, or other malicious software installed on the user
> device. During the first (or second, I can't recall) run of this
> debate, the chair *did* make a consensus call that the WG did not feel
> this was an OAuth specific threat. The chair's proposed resolution at
> the time was clearly too vague to close the issue and hence we are
> still arguing about it.

That's not exactly how I read the original request.  One part I remember
clearly was more a question about user interface and "protecting" the
User<->AS request.  I think this could've been handled by a simple
statement that "protecting a device or end-user user interface is out of
scope for OAUTH".

There was also an issue about handling bad players in the system (e.g. a
Bad Client player).  As a security person I'm afraid I do have to agree
with Michael here, a threats document cannot say that to counteract a
bad player you need to have a good player.  You need to either say that
the protocol does not protect against a bad player, or you need to say
how to protect against a bad player.  There is nothing wrong saying that
it doesn't protect against a bad player, but writing it off will
definitely make you look less credible.

> Adding the requested threat will make the document look less credible
> for stating the obvious. I do not agree that any threat mentioned
> should be listed. At some point, and we're almost there, you lose the
> forest for the trees.

And it looks credible to imply that OAUTH protects against all attacks
including the kitchen-sink attack?  Maybe it is obvious to you, but
you've been knee deep in the protocol for years.  It is not necessarily
obvious to the next person who reads the drafts.  Being honest about
what OAUTH does (and more importantly does NOT) do is more credible than
ignoring what might be obvious to some but not obvious to others.

> And BTW, as a response to Michael's original comment, I have requested
> that the threat of earthquakes will also be listed under UX
> considerations to prevent a user from clicking 'Approve' during an
> earthquake if it is too close to the 'Deny' button. Is my threat,
> which is clearly valid (no matter how unlikely), going to be added as
> well? Please don't, but I hope you see my point here. Many bad things
> can happen to you while using OAuth.

And you're worried about sounding credible by talking about bad players
and being explicit about the scope of OAUTH protection on a client
device?  Following your suggestion, ad absurdium, why not talk about the
threat of a meteor shower?  Seriously, yes, there is a line that has to
be drawn; clearly *I* needed to be more explicit about that.  Yes, of
course the threat has to actually apply, but dismissing a threat out of
hand because you don't like it or you feel it will make you look less
"credible" only makes you look less credible.

> I don't care how this is resolved. At this point I don't mind the
> threat being added just to close the issue.

Sold.  Thank you, Eran.

> EH

-derek
-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From internet-drafts@ietf.org  Thu Apr 26 07:34:14 2012
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 486A221F8775; Thu, 26 Apr 2012 07:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.507
X-Spam-Level: 
X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hXyAXmyg-zC; Thu, 26 Apr 2012 07:34:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7BE21F8766; Thu, 26 Apr 2012 07:34:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.01p1
Message-ID: <20120426143413.21001.97700.idtracker@ietfa.amsl.com>
Date: Thu, 26 Apr 2012 07:34:13 -0700
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-02.txt
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: Thu, 26 Apr 2012 14:34:14 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

	Title           : OAuth 2.0 Assertion Profile
	Author(s)       : Michael B. Jones
                          Brian Campbell
                          Yaron Y. Goland
	Filename        : draft-ietf-oauth-assertions-02.txt
	Pages           : 16
	Date            : 2012-04-26

   This specification provides a general framework for the use of
   assertions as client credentials and/or authorization grants with
   OAuth 2.0.  It includes a generic mechanism for transporting
   assertions during interactions with a token endpoint, as wells as
   rules for the content and processing of those assertions.  The intent
   is to provide an enhanced security profile by using derived values
   such as signatures or HMACs, as well as facilitate the use of OAuth
   2.0 in client-server integration scenarios where the end-user may not
   be present.

   This specification only defines abstract message flow and assertion
   content.  Actual use requires implementation of a companion protocol
   binding specification.  Additional profile documents provide standard
   representations in formats such as SAML and JWT.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-assertions-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-assertions-02.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/


From hardjono@mit.edu  Thu Apr 26 11:25:23 2012
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 B910B11E80A5 for ; Thu, 26 Apr 2012 11:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUKfkjmSOg2P for ; Thu, 26 Apr 2012 11:25:20 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 52FA211E80A1 for ; Thu, 26 Apr 2012 11:25:18 -0700 (PDT)
X-AuditID: 12074425-b7f4a6d0000008e0-1f-4f99930d8b6e
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id B9.5E.02272.D03999F4; Thu, 26 Apr 2012 14:25:17 -0400 (EDT)
Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q3QIPHAT029220 for ; Thu, 26 Apr 2012 14:25:17 -0400
Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id q3QIPH6r026038 for ; Thu, 26 Apr 2012 14:25:17 -0400
Received: from OC11EXHUB8.exchange.mit.edu (18.9.3.20) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Apr 2012 14:24:29 -0400
Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.42]) by OC11EXHUB8.exchange.mit.edu ([18.9.3.20]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 14:25:16 -0400
From: Thomas Hardjono 
To: "oauth@ietf.org" 
Thread-Topic: Updated Dynamic Registration draft --- FW: I-D Action: draft-hardjono-oauth-dynreg-03.txt
Thread-Index: Ac0j2etu69pb905pSvOQ3iJKpfyynw==
Date: Thu, 26 Apr 2012 18:25:15 +0000
Message-ID: <5E393DF26B791A428E5F003BB6C5342A107710C6@OC11EXPO24.exchange.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [18.111.67.88]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0021_01CD23B8.656C8DA0"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUgTcRjH+91tt5t4ds6X/bIsd+FrbBkkWElE9YcQZYlF+Y9d3uWutml3 c6j4h4lJOpJR9uJQ7MX+UCxTIaNQaWgyZ5b2bmEKiro0GEJvhnbXOfW/z3Pf5/nwPNwPRzXT ygics1hZ3kKbKCxAoVGHbdUT12rSEkfaY5Pdc15sH0htaPiNHAWZASkMa+JsLL997+kA44Oq DmXeRUOBvbUMLQFL8ZUAxyG5E368H1kJ1CKGw9ejLVglCMA1ZBeAX6eeoXLxDsA39usqufgM 4JeFweXiMYCLbV5ELhoBrKkdAJIMI+Pg4EKnSuJQMhp29b79zygZA9tHLislDiEZ6Ps7CuQe Di411S+zAb5w3MMkVoizo9WfEIkJMh2+XFxUSAzEZX/2NyOyUwtHJuoR+YhQOD7kwfwHLT4d x+Q7o2CDN0XaEyWvADh295FSdgZDd82EwgHCnWtUzrV9zjV9TtGFivuVtwK5fwvsmKtFZd4D b/15jsmsg9X2cZXMSfBbrw/cBngTiGTMRXozzZkENlsvZNMWC8vrkw1mzmpgmfw2IP1Q1cHo J8DholyAxAEVSNzJqUnTKGmbUGh2gQ04QoUReVfFT0FncplCIy0Ys/h8Eyu4AMRRKpQYXidm BEMXFrF8rj/aiCsoLRGf8P2Ihsyhrex5ls1jeX+6CccpSKRK0mCezWELznIm62qM4GpJHijK S6QeQsijzQKXI+f9QBehJbKkgJQCY75lZdb/QL1AK54SQmRIXYHi812Z9opiRBT/SL8hia30 ahRRAjLGPKXzyqULQe7K3dsO97BqPnN9h+k4qnTZlsz7i34hH3rexx2oK56xTVlKux/aONWh XbOTmyvQvuIT9dUzDl83x3Q6XlVEXiLKh7lZd2dLv6f5pNmTpLPH1Omq+iJ9YbFlUcxA0NDk PFNhj795LC3k3CnXxHR5Y0RiVGIZpRCM9I4ElBfof+SZBIt7AwAA
Subject: [OAUTH-WG] Updated Dynamic Registration draft --- FW: I-D Action: draft-hardjono-oauth-dynreg-03.txt
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: Thu, 26 Apr 2012 18:25:24 -0000

------=_NextPart_000_0021_01CD23B8.656C8DA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


Folks,

As I mentioned at the last IETF (via jabber), the dynreg draft is
interested primarily in dynamic client registration (not discovery).

As such I've done some house-cleaning on the dynreg draft, removing
Section 5 that has some early discussion about discovery and using
section 7.2 (now 6.2) as a placeholder for future reference (to the
discovery protocol/solution to be standardized by the OAuth WG).

cheers,

/thomas/

---------------------------------------------

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
Sent: Thursday, April 26, 2012 2:16 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-hardjono-oauth-dynreg-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : OAuth Dynamic Client Registration Protocol
	Author(s)       : Thomas Hardjono
                          Maciej Machulak
                          Eve Maler
                          Christian Scholz
	Filename        : draft-hardjono-oauth-dynreg-03.txt
	Pages           : 19
	Date            : 2012-04-26

   This specification proposes an OAuth Dynamic Client Registration
   protocol.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hardjono-oauth-dynreg-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-hardjono-oauth-dynreg-03.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------=_NextPart_000_0021_01CD23B8.656C8DA0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGezCCAzgw
ggKhoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3Nh
Y2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kx
FTATBgNVBAsTDENsaWVudCBDQSB2MTAeFw0wNjA2MDcyMjA3MjVaFw0yNjA4MDEyMjA3MjVaMGwx
CzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNl
dHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFddQmuDslk55RehR/M/DMAlGty+ScbhbKy7M+2qxnkw0t/
Vo1ssA4AmTN7zgrzqc4hhWM4nEu5+CULstOELk/ul3XNmxMe7iToaHk8/1cqQOAyMHLL9tCOtwoK
9eGjDc+VK+ClkI8p+s3IENu+n5zP3CQ98MwM19n1PZhf9SxRAgMBAAGjgekwgeYwHQYDVR0OBBYE
FAEYm49Mbcpuuj+rJQL9HgjAesKPMIGWBgNVHSMEgY4wgYuAFAEYm49Mbcpuuj+rJQL9HgjAesKP
oXCkbjBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UEChMlTWFz
c2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xpZW50IENBIHYx
ggEBMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG
9w0BAQUFAAOBgQAvyeyk0Iw11IvcQDQ1sWZinNNmJ/dEwYam4P3+3puv/Uhzvb3Ehq9OGrb3u/cA
sYDOOptR73ePd7Mck4DyUh+VJ+hqyvAkNSMqquIF74ywTkW5a4nDgp8ruSmmmetzY2MZ48L8Ddrs
vaKbLl5oozACf4C+6+BnfbyvlM7M9KpiTzCCAzswggKkoAMCAQICEBMVtE7s9o6AXkTYF/hWokow
DQYJKoZIhvcNAQEFBQAwbDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAs
BgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENs
aWVudCBDQSB2MTAeFw0xMjAxMDkxODEzMDlaFw0xMjA3MzExODEzMDlaMIGnMQswCQYDVQQGEwJV
UzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1
dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xpZW50IENBIHYxMRgwFgYDVQQDEw9UaG9tYXMg
SGFyZGpvbm8xHzAdBgkqhkiG9w0BCQEWEGhhcmRqb25vQE1JVC5FRFUwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBAM/aF8jJY8GlKpvUQsId+za72ZoM1X/OwVD95Hdzfo/51GzrWLSRPeCGpwI9
+C+E2bphW0TwKxiHCVBN3hnw3nU+Tj0ACELvad5tEzLtCkzyzuKTg1ci3JYzjkMdkmOiERbWPCvq
D/BXwyVzYyIUbF7VENDmhohw1zBhVZSmvvHlAgMBAAGjgaEwgZ4wCQYDVR0TBAIwADARBglghkgB
hvhCAQEEBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMAsGA1UdDwQEAwIF4DAd
BgNVHQ4EFgQUPsk/+hr9AJy8XtABaneCLDEtkikwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Nh
Lm1pdC5lZHUvY2EvbWl0Y2xpZW50LmNybDANBgkqhkiG9w0BAQUFAAOBgQAZ2ZyXTczFL5Zb/SrH
Q+CmEx359Dkb59X9a2jvQPO1ykDvb88ouTtiS/gldn/2Xg6AI7kwx7RL0d2F9wHj4YF0Ui2PX5bI
mYSXu/4w6pKhINpoNEBGsfy0vvdCy1JhGyqPtqnLtUeeY/YO7vb56+CDGtpIjvJfBgsWRGU4/OvR
ZDGCA2AwggNcAgEBMIGAMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4w
LAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxD
bGllbnQgQ0EgdjECEBMVtE7s9o6AXkTYF/hWokowCQYFKw4DAhoFAKCCAjUwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNDI2MTgyNTE0WjAjBgkqhkiG9w0BCQQx
FgQU1GecrnvrqpcwxKeBDbvfriMPuWkwgZEGCSsGAQQBgjcQBDGBgzCBgDBsMQswCQYDVQQGEwJV
UzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1
dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xpZW50IENBIHYxAhATFbRO7PaOgF5E2Bf4VqJK
MIGTBgsqhkiG9w0BCRACCzGBg6CBgDBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVz
ZXR0czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMG
A1UECxMMQ2xpZW50IENBIHYxAhATFbRO7PaOgF5E2Bf4VqJKMIGrBgkqhkiG9w0BCQ8xgZ0wgZow
CwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa
MAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIGA
CCIday1nbqhrEYpETR54SV/73k1GGcxPuRpWw2Mi7M9xbJE7nPQDsHHtP2kO/R5vqa5S7Wpc1sOw
0I6reKKfIUBDLoNgWXqZUzvoPSQaOksTuZPTDkmAO9e3rnSLeobdNZbHm1gVx6/JT0mrNF/jERvI
ZkxYfTr85b0I64m75mQAAAAAAAA=

------=_NextPart_000_0021_01CD23B8.656C8DA0--

From eran@hueniverse.com  Thu Apr 26 11:54:23 2012
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 26F5B21E8160 for ; Thu, 26 Apr 2012 11:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level: 
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-jy+JNAJ1W0 for ; Thu, 26 Apr 2012 11:54:22 -0700 (PDT)
Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1D68D21E816D for ; Thu, 26 Apr 2012 11:54:22 -0700 (PDT)
Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id 2iuM1j0030EuLVk01iuM6M; Thu, 26 Apr 2012 11:54:21 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Thu, 26 Apr 2012 11:54:21 -0700
From: Eran Hammer 
To: Thomas Hardjono , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Updated Dynamic Registration draft --- FW: I-D Action: draft-hardjono-oauth-dynreg-03.txt
Thread-Index: Ac0j2etu69pb905pSvOQ3iJKpfyynwABASMQ
Date: Thu, 26 Apr 2012 18:54:20 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20100D38B@P3PWEX2MB008.ex2.secureserver.net>
References: <5E393DF26B791A428E5F003BB6C5342A107710C6@OC11EXPO24.exchange.mit.edu>
In-Reply-To: <5E393DF26B791A428E5F003BB6C5342A107710C6@OC11EXPO24.exchange.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [161.163.44.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Updated Dynamic Registration draft --- FW: I-D Action: draft-hardjono-oauth-dynreg-03.txt
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: Thu, 26 Apr 2012 18:54:23 -0000

Thanks! This removes all my concerns about the charter.

EH

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Thomas Hardjono
> Sent: Thursday, April 26, 2012 11:25 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Updated Dynamic Registration draft --- FW: I-D Action=
:
> draft-hardjono-oauth-dynreg-03.txt
>=20
>=20
> Folks,
>=20
> As I mentioned at the last IETF (via jabber), the dynreg draft is interes=
ted
> primarily in dynamic client registration (not discovery).
>=20
> As such I've done some house-cleaning on the dynreg draft, removing
> Section 5 that has some early discussion about discovery and using sectio=
n
> 7.2 (now 6.2) as a placeholder for future reference (to the discovery
> protocol/solution to be standardized by the OAuth WG).
>=20
> cheers,
>=20
> /thomas/
>=20
> ---------------------------------------------
>=20
> -----Original Message-----
> From: i-d-announce-bounces@ietf.org
> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Thursday, April 26, 2012 2:16 PM
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-hardjono-oauth-dynreg-03.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
> 	Title           : OAuth Dynamic Client Registration Protocol
> 	Author(s)       : Thomas Hardjono
>                           Maciej Machulak
>                           Eve Maler
>                           Christian Scholz
> 	Filename        : draft-hardjono-oauth-dynreg-03.txt
> 	Pages           : 19
> 	Date            : 2012-04-26
>=20
>    This specification proposes an OAuth Dynamic Client Registration
>    protocol.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hardjono-oauth-dynreg-03.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-hardjono-oauth-dynreg-03.txt
>=20
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From internet-drafts@ietf.org  Thu Apr 26 12:34:26 2012
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 E0B6921E817D; Thu, 26 Apr 2012 12:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.498
X-Spam-Level: 
X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouCbsy5uANOd; Thu, 26 Apr 2012 12:34:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812B221E8173; Thu, 26 Apr 2012 12:34:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.01p1
Message-ID: <20120426193425.6324.14298.idtracker@ietfa.amsl.com>
Date: Thu, 26 Apr 2012 12:34:25 -0700
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-11.txt
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: Thu, 26 Apr 2012 19:34:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Web Authorization Protocol Working Gr=
oup of the IETF.

	Title           : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
	Author(s)       : Chuck Mortimore
	Filename        : draft-ietf-oauth-saml2-bearer-11.txt
	Pages           : 16
	Date            : 2012-04-26

   This specification defines the use of a SAML 2.0 Bearer Assertion as
   a means for requesting an OAuth 2.0 access token as well as for use
   as a means of client authentication.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-11.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/


From bcampbell@pingidentity.com  Thu Apr 26 13:01:01 2012
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 EBED321E808D for ; Thu, 26 Apr 2012 13:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.942
X-Spam-Level: 
X-Spam-Status: No, score=-5.942 tagged_above=-999 required=5 tests=[AWL=0.035,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k32V1Xha3RNZ for ; Thu, 26 Apr 2012 13:01:01 -0700 (PDT)
Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id A976D21E8088 for ; Thu, 26 Apr 2012 13:01:00 -0700 (PDT)
Received: from mail-vb0-f43.google.com ([209.85.212.43]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKT5mpeyRCxDtqTkK+Pxbuq6UBTzb7vD46@postini.com; Thu, 26 Apr 2012 13:01:00 PDT
Received: by vbbfq11 with SMTP id fq11so1639718vbb.2 for ; Thu, 26 Apr 2012 13:00:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=Wq4qBR/g3puCLWv/U+/TaU0rCcvqtTWsabcb5cUU88A=; b=Gmj9k9yiHHyQAFrRuw21zclh9dgkS+J77vh8t45AIxxXI/YH+Kb51YZktqfx2frTZY orRQnCnjkeTaKv1Le8O1lMxLNzDDZMREydjMAnpIBEcw7+Co5Q5Rrdt2JtxDdOGB+CYv 4A2AjR4+sI238OMuN6cnhleSKwTKNjpXpzUh+98x5C9JVObwy6ul2s6SqyEVSsaIgUt8 mE8/9nfflxAm6MTFVqAF+lCurTQhjC7BIrR2aTARyVDTq9xwB2G1sgV+6j5Kklw6VScF muK2fw3YqaPrsX6NtqTqDAzwjxDscc3i9p9eW0QLpg3MgyN5sK6C+nSatVVZ2uX+PiGs f8tw==
Received: by 10.52.90.175 with SMTP id bx15mr7300162vdb.31.1335470459046; Thu, 26 Apr 2012 13:00:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.38.104 with HTTP; Thu, 26 Apr 2012 13:00:28 -0700 (PDT)
From: Brian Campbell 
Date: Thu, 26 Apr 2012 14:00:28 -0600
Message-ID: 
To: oauth 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQl9MmL9IrxyHdUFvq8fH0SCVVnKevF8kqx1AKYi4lUHHyz2w+0/sFI2Pfhtix/g8tJEh2iq
Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Draft -11 and OAuth 2.0 Assertion Profile Draft -02
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: Thu, 26 Apr 2012 20:01:02 -0000

Draft -11 of "SAML 2.0 Bearer Assertion Profiles for OAuth 2.0" and
draft -02 of "OAuth 2.0 Assertion Profile" have been published. The
changes address comments raised during WGLC on the two documents that
ended earlier this week. A summary of changes is included (with links
to the comment in the mail archive when appropriate) in the document
history section of each draft. A copy of the relevant portion of the
history is also copied to the bottom of this message for convenience.
I'd like to specifically thank Mike Jones for his assistance in
getting these updates posted quickly.

The drafts are available at:

http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-11

http://tools.ietf.org/html/draft-ietf-oauth-assertions-02




draft-ietf-oauth-saml2-bearer-11

   o  Removed text about limited lifetime access tokens and the SHOULD
      NOT on issuing refresh tokens.  The text was moved to
      draft-ietf-oauth-assertions-02 and somewhat modified per
      http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html.

   o  Fixed typo/missing word per
      http://www.ietf.org/mail-archive/web/oauth/current/msg08733.html.

   o  Added Terminology section.



 draft-ietf-oauth-assertions-02

   o  Added text about limited lifetime ATs and RTs per
      http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html.

   o  Changed the line breaks in some examples to avoid awkward
      rendering to text format.  Also removed encoded '=' padding from a
      few examples because both known derivative specs, SAML and JWT,
      omit the padding char in serialization/encoding.

   o  Remove section 7 on error responses and move that (somewhat
      modified) content into subsections of section 4 broken up by
      authn/authz per
      http://www.ietf.org/mail-archive/web/oauth/current/msg08735.html.

   o  Rework the text about "MUST validate ... in order to establish a
      mapping between ..." per
      http://www.ietf.org/mail-archive/web/oauth/current/msg08872.html
      and
      http://www.ietf.org/mail-archive/web/oauth/current/msg08749.html.

   o  Change "The Principal MUST identify an authorized accessor.  If
      the assertion is self-issued, the Principal SHOULD be the
      client_id" in 6.1 per
      http://www.ietf.org/mail-archive/web/oauth/current/msg08873.html.

   o  Update reference in 4.1 to point to 2.3 (rather than 3.2) of
      oauth-v2 (rather than self)
      http://www.ietf.org/mail-archive/web/oauth/current/msg08874.html.

   o  Move the "Section 3 of" out of the xref to hopefully fix the link
      in 4.1 and remove the client_id bullet from 4.2 per
      http://www.ietf.org/mail-archive/web/oauth/current/msg08875.html.

   o  Add ref to Section 3.3 of oauth-v2 for scope definition and remove
      some then redundant text per
      http://www.ietf.org/mail-archive/web/oauth/current/msg08890.html.

   o  Change "The following format and processing rules SHOULD be
      applied" to "The following format and processing rules apply" in
      sections 6.x to remove conflicting normative qualification of
      other normative statements per
      http://www.ietf.org/mail-archive/web/oauth/current/msg08892.html.

   o  Add text the client_id must id the client to 4.1 and remove
      similar text from other places per
      http://www.ietf.org/mail-archive/web/oauth/current/msg08893.html.

   o  Remove the MUST from the text prior to the HTTP parameter
      definitions per
      http://www.ietf.org/mail-archive/web/oauth/current/msg08920.html.

   o  Updated examples to use grant_type and client_assertion_type
      values from the OAuth SAML Assertion Profiles spec.



-- Brian

From Michael.Jones@microsoft.com  Thu Apr 26 13:53:54 2012
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 5348C21E8157 for ; Thu, 26 Apr 2012 13:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.398
X-Spam-Level: 
X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[AWL=1.200,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnCmrhZoOQTr for ; Thu, 26 Apr 2012 13:53:52 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id E37F811E80A3 for ; Thu, 26 Apr 2012 13:53:50 -0700 (PDT)
Received: from mail182-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 20:53:49 +0000
Received: from mail182-tx2 (localhost [127.0.0.1])	by mail182-tx2-R.bigfish.com (Postfix) with ESMTP id 03F9A2A040C	for ; Thu, 26 Apr 2012 20:53:49 +0000 (UTC)
X-SpamScore: -19
X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail182-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail182-tx2 (localhost.localdomain [127.0.0.1]) by mail182-tx2 (MessageSwitch) id 1335473626656302_21790; Thu, 26 Apr 2012 20:53:46 +0000 (UTC)
Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.240])	by mail182-tx2.bigfish.com (Postfix) with ESMTP id 9A69E8011D	for ; Thu, 26 Apr 2012 20:53:46 +0000 (UTC)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 20:53:45 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Thu, 26 Apr 2012 20:53:43 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: OAuth 2.0 JWT Bearer Token Profiles Specification Draft -04
Thread-Index: Ac0j7qUkXVRjqDKuTWWLAyS7pQtPGw==
Date: Thu, 26 Apr 2012 20:53:43 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436649B615@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.73]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436649B615TK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: [OAUTH-WG] OAuth 2.0 JWT Bearer Token Profiles Specification Draft -04
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: Thu, 26 Apr 2012 20:53:54 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436649B615TK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Draft 04 of the OAuth 2.0 JWT Bearer Token Profiles Specification has been published.  This v=
ersion tracks changes in the OAuth 2.0 Assertion Profile and SAML 2.0 Bearer Assertion Profile=
s for OAuth 2.0 s=
pecifications made in response to working group last call comments, as anno=
unced by Brian Campbell.

Changes made were:

  *   Merged in changes between draft-ietf-oauth-saml2-bearer-09 and draft-=
ietf-oauth-saml2-bearer-11.
  *   Added the optional iat (issued at) claim, which was already present i=
n the JWT spec.

The draft is available at:

*         http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-04
An HTML-formatted version is available at:

*         http://self-issued.info/docs/draft-jones-oauth-jwt-bearer-04.html

                                                                -- Mike


--_000_4E1F6AAD24975D4BA5B16804296739436649B615TK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Draft 04 of the 
OAuth 2.0 JWT Bearer Token Profiles Specification has been published.&n=
bsp; This version tracks changes in the
OAuth 2.=
0 Assertion Profile and
SAML 2=
.0 Bearer Assertion Profiles for OAuth 2.0 specifications made in respo=
nse to working group last call comments, as
announced by Brian Campbell.


 


Changes made were:


    

  • Merged in changes between draft-ietf-oauth-saml2-bearer=
-09 and draft-ietf-oauth-saml2-bearer-11.

  • Added the optional
iat (issued at) =
claim, which was already present in the JWT spec.



 


The draft is available at:


·        
http://tools.ietf.org/html/draft-jones-oauth-jwt=
-bearer-04


An HTML-formatted version is available at:


·        
http://self-issued.info/docs/draft-jones-=
oauth-jwt-bearer-04.html


 


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     -- Mike


 






--_000_4E1F6AAD24975D4BA5B16804296739436649B615TK5EX14MBXC284r_--

From barryleiba.mailing.lists@gmail.com  Thu Apr 26 18:28:21 2012
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 355D811E8091 for ; Thu, 26 Apr 2012 18:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.962
X-Spam-Level: 
X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akVRZb02NSvU for ; Thu, 26 Apr 2012 18:28:20 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83B9811E8079 for ; Thu, 26 Apr 2012 18:28:20 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so146081ghb.31 for ; Thu, 26 Apr 2012 18:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=FQzcXV+V1ucw2FqX2XX6U9Chgs4v//EWvmdlVDV6+hc=; b=jEdnOh4TXNiH7yO76gFxGRBYfKCrq/BS/JGsJoYvcjJyU5D/9g0ECpsJpWdiSdr40F BOJAodrkoE3pyVUYaSkTGlaYq3DoifFsm002D0hH4IaLWoqDGEwml/ZS4gEMPeX+13IP kCnz5Bs7dQUz/6hseaHciOJksJ0xWl7+AdKw06eEhYRRGc63EnUc2+I30cZ5JDt4sIp6 pZugAumBe8e4AGz1m8d+bcX6brtW0makhWvuMDAZGlodRJ74FYI1PIufJV6MvpduIWWH 7DnnR6HjjjgCh1FLWt7UGe3fz1GuNosysG73Ki66xN5zTLuYgi2IFw+F4JUDikYJnwWU 50/A==
MIME-Version: 1.0
Received: by 10.236.185.10 with SMTP id t10mr8981755yhm.112.1335490100103; Thu, 26 Apr 2012 18:28:20 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.152.14 with HTTP; Thu, 26 Apr 2012 18:28:19 -0700 (PDT)
In-Reply-To: <580607FC-28EC-4BBA-8CBA-C63D2FA52C8E@oracle.com>
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net> <580607FC-28EC-4BBA-8CBA-C63D2FA52C8E@oracle.com>
Date: Thu, 26 Apr 2012 21:28:19 -0400
X-Google-Sender-Auth: K2PlQI3ejfRdNd3PlbBZzY_QJZ0
Message-ID: 
From: Barry Leiba 
To: oauth@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Fri, 27 Apr 2012 01:28:21 -0000

Phil said...

> **However** =A0Editorially I feel strongly the comments fall outside the =
intended scope
> and purpose for this document. This document is about threats specificall=
y related
> to the OAuth protocol. =A0It's intent is to go beyond security considerat=
ions to give
> implementers a feel for the issues the group has considered specific to t=
he protocol.
>
> Michael's comments are directed at general trusted computing platform. An=
d while I
> agree they are valid, they don't fit in this document.

I'll add one thing to this consideration:  while I agree that we can't
discuss every threat that one might encounter in a web services
environment, I think it's useful and important to discuss issues that
people are likely to think are addressed, mitigated, or solved by
OAuth, *even if we don't think that, and even if we know they're not
really OAuth issues.*

DKIM had a related problem (which I do NOT want to open up for
discussion here; I mention it only for comparison).  DKIM was often
oversold as being something that would "block spam" or "stop phishing
in its tracks."  It will do neither, though it's a tool to be used in
systems that aim at both.  Similarly, while OAuth solves a real
problem and is a good step, it will not *stop* impersonation attacks,
credential-theft attacks, and so on.  We all know that, but many
people who will read the OAuth spec will think it can do that.  The
threats document should be addressing that "overselling" problem[1],
and if that means highlighting a few things that we think should be
obvious, I'm in favour of it.

I think the things that Mike Thomas has bought up fall into that
category.  I'm sympathetic to the argument that this is a long
document, bordering on (or perhaps having crossed the border into)
"tl;dr" territory.  Perhaps there are other things that can be
trimmed.  But at this point, I've made a proposal to add a few
paragraphs, and mostly (not completely) gotten feedback from the
editors that my text is acceptable.  Mike has asked for one paragraph
to be added to that, and I think his proposal is reasonable.  If we go
with that set of additions, I think we'll address some of the
overselling problem, and I think the document will be better for it.

If the editors want to post my suggested addition here, they may do
so; yes, it was meant for a small group to iron out first, but the WG
will have to see and agree to it at some point anyway.  If the editors
want to trim a bit elsewhere in the document to make room, they may
also do that -- with the consent of the WG.  But let's please not get
hung up on this to the point of losing traction on the whole document.

And everyone please relax and not get hot or snarky: we're all trying
to make a better document, and calm discussion, rather than sarcasm
and hyperbole, is the best way to do that.  We're almost there.  We'll
get there soon.

Barry, document shepherd

From barryleiba.mailing.lists@gmail.com  Thu Apr 26 18:31:30 2012
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 9B18811E8097 for ; Thu, 26 Apr 2012 18:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.962
X-Spam-Level: 
X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNJ+vn06GQ46 for ; Thu, 26 Apr 2012 18:31:30 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B06811E8096 for ; Thu, 26 Apr 2012 18:31:30 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so149605yhk.31 for ; Thu, 26 Apr 2012 18:31:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=UMHXn29dMPhgu/9i81AtBwc76snQyMJFPrdofP6TS5w=; b=DSlqvvqALbb9GSDihCE2G4hG4HbgPzMKH+xKupS/GkmrSXnGMCCVXsQKN1CPQjXw1A sP3cje4z6tiBKSQRcePEreNzBWotoAzNsavnEA6nCN+F97kbSBAHSZpkU16y5AxWdBsz DLm35sxcG0sT+Hv8nyKWeG/U3Lnk8+7hcseFWiUYOtxkx5iaDhmQ8jRR5Ulj/XWFlWng X+PwhgcLbO9QSRI1g4k3/jY+dLR1DZF+b0ob7HjNxOLmocYlDalhxzSX0BWBNVWPfmmz zMbDjVfN/AYmpOv6pazkOtV414/30ofCnk5wWv8WwSBV2lnyOkK1haCBc+9S5hnRhgyH 5Wlw==
MIME-Version: 1.0
Received: by 10.236.154.35 with SMTP id g23mr8963608yhk.107.1335490289607; Thu, 26 Apr 2012 18:31:29 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.152.14 with HTTP; Thu, 26 Apr 2012 18:31:29 -0700 (PDT)
In-Reply-To: 
References:  <4F8DE789.4030704@mtcc.com>  <4F957EA7.3060004@mtcc.com>  <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net> <580607FC-28EC-4BBA-8CBA-C63D2FA52C8E@oracle.com> 
Date: Thu, 26 Apr 2012 21:31:29 -0400
X-Google-Sender-Auth: 9wpLbvLdhO4h2LxRPGhYvx0tEGk
Message-ID: 
From: Barry Leiba 
To: oauth@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
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: Fri, 27 Apr 2012 01:31:30 -0000

Oh, and sorry...

> threats document should be addressing that "overselling" problem[1],
> and if that means highlighting a few things that we think should be
> obvious, I'm in favour of it.

...I forgot to include the footnote.

Barry

[1] Note that I'm NOT saying that the WG is overselling OAuth, but
that any technology like this gets oversold in the press, by
implementors who want to make its support part of a sales pitch, and
by general word of mouth/blog/twit.

From Hannes.Tschofenig@gmx.net  Mon Apr 30 17:45:40 2012
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 93D6D21E8129 for ; Mon, 30 Apr 2012 17:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7ijR-ycEqQ9 for ; Mon, 30 Apr 2012 17:45:40 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7964821E8126 for ; Mon, 30 Apr 2012 17:45:39 -0700 (PDT)
Received: (qmail invoked by alias); 01 May 2012 00:45:38 -0000
Received: from user-64-9-236-105.googlewifi.com (EHLO user-64-9-236-105.googlewifi.com) [64.9.236.105] by mail.gmx.net (mp039) with SMTP; 01 May 2012 02:45:38 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/Z9f9LOV3ZXY89HciBDRhL+80yIU+iA29Vr8NYg1 M54s7phH/SAdFk
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 1 May 2012 03:45:32 +0300
Message-Id: <0B9C43D3-774C-44D7-9BC2-A00A12C1F36A@gmx.net>
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] IIW
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: Tue, 01 May 2012 00:45:40 -0000

Hi all,=20

thanks for the response regarding the IIW/OAuth breakfast.=20

Here is my proposal:=20

* During IIW event we meet in the morning for breakfast in the Computer =
History museum and "hijack" one of the tables and use it for OAuth =
discussions.=20

* Those who are interested meet at the Red Rock Coffee =
http://www.redrockcoffee.org/ on Friday after IIW at 9 am.=20

Ciao
Hannes