Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
Justin Richer <jricher@mitre.org> Thu, 14 February 2013 14:29 UTC
Return-Path: <jricher@mitre.org>
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 9383921F8682 for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 06:29:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Level:
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmR+gI+oEL0C for <oauth@ietfa.amsl.com>; Thu, 14 Feb 2013 06:29:47 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1148521F8691 for <oauth@ietf.org>; Thu, 14 Feb 2013 06:29:46 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 917A45310DC7; Thu, 14 Feb 2013 09:29:45 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7D20E5310DC5; Thu, 14 Feb 2013 09:29:45 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 09:29:45 -0500
Message-ID: <511CF4AB.5010700@mitre.org>
Date: Thu, 14 Feb 2013 09:28:59 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Prabath Siriwardena <prabath@wso2.com>
References: <20130206192420.32698.21027.idtracker@ietfa.amsl.com> <5112AE0B.1080501@mitre.org> <CAJV9qO_8-4FowrXK=ae-+xMjiJFP04ryVMLQ8SGUH8kp3PHrLg@mail.gmail.com> <5113C3AA.1040701@mitre.org> <CAJV9qO8BVV57eAb5kUNes15AYOpUKqw5XWQswh-FJA=b1pPgSA@mail.gmail.com> <5113DDB2.7060805@mitre.org> <CAJV9qO_gM1oera9ae9sqh9n17e-ZLKuC2pmsZwhq-RmFcMyqHA@mail.gmail.com> <51196777.6000502@mitre.org> <CAJV9qO-5bWZbNUfCmaqYBQoy-qwNaSZFOsO9GL3CrbSejwVTzw@mail.gmail.com> <F6595A40-6B4E-4718-ABB5-694CA975C4DB@maymount.com> <511A5062.5010108@mitre.org> <CAJV9qO_Mr87NX=KZRqCsWasQ1FuvDNBw14eS-TcPf_KRJztQFg@mail.gmail.com> <CAJV9qO-71-sM6kXOB6Fb_bvVkDBQ5JBbs8E5X=f-K=iEmGezRA@mail.gmail.com> <511CEEAA.3030801@mitre.org> <CAJV9qO-JSXgSTkw2_pdH0D-o-xDWGDqxx=PAWYtnTj4hOQXW4Q@mail.gmail.com> <CAJV9qO9=+kiO-s7vH_ewr7XjfVdDU24F0kuif504bP53dBr1TA@mail.gmail.com> <511CF3EF.8040008@mitre.org> <CAJV9qO8yKkrsV7d9JtDmbLY-fb5phh=ssKbEUuutkY53PgY8Vg@mail.gmail.com>
In-Reply-To: <CAJV9qO8yKkrsV7d9JtDmbLY-fb5phh=ssKbEUuutkY53PgY8Vg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------090306090907080103010008"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2013 14:29:49 -0000
Because it will be the one that issued the token in the first place. Validity means "token was issued from here, it hasn't been revoked, it hasn't expired". -- Justin On 02/14/2013 09:28 AM, Prabath Siriwardena wrote: > Okay. With out knowing the type of the token how can the AS validate > the token ? What is meant by the validity there? > > Thanks & regards, > -Prabath > > On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer <jricher@mitre.org > <mailto:jricher@mitre.org>> wrote: > > OK, I don't see the utility in that at all. What would it accomplish? > > -- Justin > > > On 02/14/2013 09:25 AM, Prabath Siriwardena wrote: >> To make it clear - my suggestion is to add token_type_hint to the >> introspection request. It can be from client to AS or from RS to AS. >> >> Then AS can decide whether the provided token is valid or not and >> include "valid" attribute in the introspection response. >> >> Thanks & regards, >> -Prabath >> >> On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena >> <prabath@wso2.com <mailto:prabath@wso2.com>> wrote: >> >> Both the client and the resource owner should be aware of the >> token type. >> >> My argument is, if the authorization server to decide whether >> the token is valid or not ( irrespective of who asked the >> question) - AS needs to know the token type - because to >> validate a token AS should know the token type. >> >> The token type could be, bearer or MAC or any other token type. >> >> Thanks & regards, >> -Prabath >> >> >> On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer >> <jricher@mitre.org <mailto:jricher@mitre.org>> wrote: >> >> What exactly are you suggesting be added to >> introspection? The "token_type_hint" is from the client >> to the server, but what you've asked for in terms of >> "token type" is from the server to the client. And there >> was never an answer to what exactly is meant by "token >> type" in this case, particularly because you seem to want >> to call out things like SAML and Bearer as separate types. >> >> -- Justin >> >> >> >> On 02/14/2013 06:59 AM, Prabath Siriwardena wrote: >>> I noticed that the latest Token Revocation draft [1] has >>> introduced the parameter "token_type_hint". I would >>> suggest the same here, as that would make what is meant >>> by "valid" much clear.. >>> >>> [1]: >>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-05 >>> >>> Thanks & regards, >>> -Prabath >>> >>> On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena >>> <prabath@wso2.com <mailto:prabath@wso2.com>> wrote: >>> >>> Hi Justin, >>> >>> I doubt whether valid_token would make a difference..? >>> >>> My initial argument is what is the validation >>> criteria..? Validation criteria depends on the >>> token_type.. >>> >>> If we are talking only about metadata - then I >>> believe "revoked", "expired" would be more meaningful.. >>> >>> Thanks & regards, >>> -Prabath >>> >>> >>> On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer >>> <jricher@mitre.org <mailto:jricher@mitre.org>> wrote: >>> >>> OK, I can see the wisdom in changing this term. >>> >>> I picked "valid" because I wanted a simple >>> "boolean" value that would require no additional >>> parsing or string-matching on the client's >>> behalf, and I'd like to stick with that. OAuth >>> is built with the assumption that clients need >>> to be able to recover from invalid tokens at any >>> stage, so I think a simple yes/no is the right >>> step here. >>> >>> That said, I think you're both right that >>> "valid" seems to have caused a bit of confusion. >>> I don't want to go with "revoked" because I'd >>> rather have the "token is OK" be the positive >>> boolean value. >>> >>> Would "valid_token" be more clear? Or do we need >>> a different adjective all together? >>> >>> -- Justin >>> >>> >>> On 02/11/2013 08:02 PM, Richard Harrington wrote: >>>> Have you considered "status" instead of >>>> "valid"? It could have values like "active", >>>> "expired", and "revoked". >>>> >>>> Is it worthwhile including the status of the >>>> client also? For example, a client application >>>> could be disabled, temporarily or permanently, >>>> and thus disabling its access tokens as well. >>>> >>>> >>>> On Feb 11, 2013, at 1:56 PM, Prabath >>>> Siriwardena <prabath@wso2.com >>>> <mailto:prabath@wso2.com>> wrote: >>>> >>>>> I guess confusion is with 'valid' parameter is >>>>> in the response.. >>>>> >>>>> I thought this will be helpful >>>>> to standardize the communication between >>>>> Resource Server and the Authorization Server.. >>>>> >>>>> I would suggest we completely remove "valid" >>>>> from the response - or define it much clearly.. >>>>> >>>>> May be can add "revoked" with a boolean >>>>> attribute.. >>>>> >>>>> Thanks & regards, >>>>> -Prabath >>>>> >>>>> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer >>>>> <jricher@mitre.org <mailto:jricher@mitre.org>> >>>>> wrote: >>>>> >>>>> >>>>> On 02/08/2013 12:51 AM, Prabath >>>>> Siriwardena wrote: >>>>>> Hi Justin, >>>>>> >>>>>> I have couple of questions related to >>>>>> "valid" parameter... >>>>>> >>>>>> This endpoint can be invoked by the >>>>>> Resource Server in runtime... >>>>> >>>>> That's correct. >>>>> >>>>> >>>>>> >>>>>> In that case what is exactly meant by the >>>>>> "resource_id" in request ? >>>>> >>>>> The resource_id field is a >>>>> service-specific string that basically >>>>> lets the resource server provide some >>>>> context to the request to the auth server. >>>>> There have been some other suggestions >>>>> like client IP address, but I wanted to >>>>> put this one in because it seemed to be a >>>>> common theme. The client is trying to do >>>>> *something* with the token, after all, and >>>>> the rights, permissions, and metadata >>>>> associated with the token could change >>>>> based on that. Since the Introspection >>>>> endpoint is all about getting that >>>>> metadata back to the PR, this seemed like >>>>> a good idea. >>>>> >>>>> >>>>>> >>>>>> IMO a token to be valid depends on set of >>>>>> criteria based on it's type.. >>>>>> >>>>>> For a Bearer token.. >>>>>> >>>>>> 1. Token should not be expired >>>>>> 2. Token should not be revoked. >>>>>> 3. The scope the token issued should >>>>>> match with the scope required for the >>>>>> resource. >>>>>> >>>>>> For a MAC token... >>>>>> >>>>>> 1. Token not expired (mac id) >>>>>> 2. Token should not be revoked >>>>>> 3. The scope the token issued should >>>>>> match with the scope required for the >>>>>> resource. >>>>>> 4. HMAC check should be valid >>>>>> >>>>>> There are similar conditions for SAML >>>>>> bearer too.. >>>>> >>>>> This isn't really true. The SAML bearer >>>>> token is fully self-contained and doesn't >>>>> change based on other parameters in the >>>>> message, unlike MAC. Same with JWT. When >>>>> it hands a SAML or JWT token to the AS, >>>>> the PR has given *everything* the server >>>>> needs to check that token's validity and use. >>>>> >>>>> MAC signatures change with every message, >>>>> and they're done across several components >>>>> of the HTTP message. Therefor, the HMAC >>>>> check for MAC style tokens will still need >>>>> to be done by the protected resource. >>>>> Introspection would help in the case that >>>>> the signature validated just fine, but the >>>>> token might have expired. Or you need to >>>>> know what scopes apply. Introspection >>>>> isn't to fully validate the call to the >>>>> protected resource -- if that were the >>>>> case, the PR would have to send some kind >>>>> of encapsulated version of the original >>>>> request. Otherwise, the AS won't have all >>>>> of the information it needs to check the MAC. >>>>> >>>>> >>>>> I think what you're describing is >>>>> ultimately *not* what the introspection >>>>> endpoint is intended to do. If that's >>>>> unclear from the document, can you please >>>>> suggest text that would help clear the use >>>>> case up? I wouldn't want it to be ambiguous. >>>>> >>>>> -- Justin >>>>> >>>>> >>>>>> >>>>>> Thanks & regards, >>>>>> -Prabath >>>>>> >>>>>> >>>>>> On Thu, Feb 7, 2013 at 10:30 PM, Justin >>>>>> Richer <jricher@mitre.org >>>>>> <mailto:jricher@mitre.org>> wrote: >>>>>> >>>>>> It validates the token, which would >>>>>> be either the token itself in the >>>>>> case of Bearer or the token "id" part >>>>>> of something more complex like MAC. >>>>>> It doesn't directly validate the >>>>>> usage of the token, that's still up >>>>>> to the PR to do that. >>>>>> >>>>>> I nearly added a "token type" field >>>>>> in this draft, but held back because >>>>>> there are several kinds of "token >>>>>> type" that people talk about in >>>>>> OAuth. First, there's "Bearer" vs. >>>>>> "MAC" vs. "HOK", or what have you. >>>>>> Then within Bearer you have "JWT" or >>>>>> "SAML" or "unstructured blob". Then >>>>>> you've also got "access" vs. >>>>>> "refresh" and other flavors of token, >>>>>> like the id_token in OpenID Connect. >>>>>> >>>>>> Thing is, the server running the >>>>>> introspection endpoint will probably >>>>>> know *all* of these. But should it >>>>>> tell the client? If so, which of the >>>>>> three, and what names should the >>>>>> fields be? >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> On 02/07/2013 11:26 AM, Prabath >>>>>> Siriwardena wrote: >>>>>>> Okay.. I was thinking this could be >>>>>>> used as a way to validate the token >>>>>>> as well. BTW even in this case >>>>>>> shouldn't communicate the type of >>>>>>> token to AS? For example in the case >>>>>>> of SAML profile - it could be SAML >>>>>>> token.. >>>>>>> >>>>>>> Thanks & regards, >>>>>>> -Prabath >>>>>>> >>>>>>> On Thu, Feb 7, 2013 at 8:39 PM, >>>>>>> Justin Richer <jricher@mitre.org >>>>>>> <mailto:jricher@mitre.org>> wrote: >>>>>>> >>>>>>> "valid" might not be the best >>>>>>> term, but it's meant to be a >>>>>>> field where the server says "yes >>>>>>> this token is still good" or "no >>>>>>> this token isn't good anymore". >>>>>>> We could instead do this with >>>>>>> HTTP codes or something but I >>>>>>> went with a pure JSON response. >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> >>>>>>> On 02/06/2013 10:47 PM, Prabath >>>>>>> Siriwardena wrote: >>>>>>>> Hi Justin, >>>>>>>> >>>>>>>> I believe this is addressing >>>>>>>> one of the key missing part in >>>>>>>> OAuth 2.0... >>>>>>>> >>>>>>>> One question - I guess this was >>>>>>>> discussed already... >>>>>>>> >>>>>>>> In the spec - in the >>>>>>>> introspection response it has >>>>>>>> the attribute "valid" - this is >>>>>>>> basically the validity of the >>>>>>>> token provided in the request. >>>>>>>> >>>>>>>> Validation criteria depends on >>>>>>>> the token and well as token >>>>>>>> type ( Bearer, MAC..). >>>>>>>> >>>>>>>> In the spec it seems like it's >>>>>>>> coupled with Bearer token >>>>>>>> type... But I guess, by adding >>>>>>>> "token_type" to the request we >>>>>>>> can remove this dependency. >>>>>>>> >>>>>>>> WDYT..? >>>>>>>> >>>>>>>> Thanks & regards, >>>>>>>> -Prabath >>>>>>>> >>>>>>>> On Thu, Feb 7, 2013 at 12:54 >>>>>>>> AM, Justin Richer >>>>>>>> <jricher@mitre.org >>>>>>>> <mailto:jricher@mitre.org>> wrote: >>>>>>>> >>>>>>>> Updated introspection draft >>>>>>>> based on recent comments. >>>>>>>> Changes include: >>>>>>>> >>>>>>>> - "scope" return parameter >>>>>>>> now follows RFC6749 format >>>>>>>> instead of JSON array >>>>>>>> - "subject" -> "sub", and >>>>>>>> "audience" -> "aud", to be >>>>>>>> parallel with JWT claims >>>>>>>> - clarified what happens >>>>>>>> if the authentication is bad >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>> >>>>>>>> -------- Original Message >>>>>>>> -------- >>>>>>>> Subject: New Version >>>>>>>> Notification for >>>>>>>> draft-richer-oauth-introspection-02.txt >>>>>>>> >>>>>>>> Date: Wed, 6 Feb 2013 >>>>>>>> 11:24:20 -0800 >>>>>>>> From: >>>>>>>> <internet-drafts@ietf.org> >>>>>>>> <mailto:internet-drafts@ietf.org> >>>>>>>> >>>>>>>> To: <jricher@mitre.org> >>>>>>>> <mailto:jricher@mitre.org> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A new version of I-D, draft-richer-oauth-introspection-02.txt >>>>>>>> has been successfully submitted by Justin Richer and posted to the >>>>>>>> IETF repository. >>>>>>>> >>>>>>>> Filename: draft-richer-oauth-introspection >>>>>>>> Revision: 02 >>>>>>>> Title: OAuth Token Introspection >>>>>>>> Creation date: 2013-02-06 >>>>>>>> WG ID: Individual Submission >>>>>>>> Number of pages: 6 >>>>>>>> URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-02.txt >>>>>>>> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>>>>>>> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-02 >>>>>>>> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-02 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> This specification defines a method for a client or protected >>>>>>>> resource to query an OAuth authorization server to determine meta- >>>>>>>> information about an OAuth token. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The IETF Secretariat >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> <mailto:OAuth@ietf.org> >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks & Regards, >>>>>>>> Prabath >>>>>>>> >>>>>>>> Mobile : +94 71 809 6732 >>>>>>>> <tel:%2B94%2071%20809%206732> >>>>>>>> >>>>>>>> http://blog.facilelogin.com >>>>>>>> http://RampartFAQ.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks & Regards, >>>>>>> Prabath >>>>>>> >>>>>>> Mobile : +94 71 809 6732 >>>>>>> <tel:%2B94%2071%20809%206732> >>>>>>> >>>>>>> http://blog.facilelogin.com >>>>>>> http://RampartFAQ.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thanks & Regards, >>>>>> Prabath >>>>>> >>>>>> Mobile : +94 71 809 6732 >>>>>> <tel:%2B94%2071%20809%206732> >>>>>> >>>>>> http://blog.facilelogin.com >>>>>> http://RampartFAQ.com >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> Prabath >>>>> >>>>> Mobile : +94 71 809 6732 >>>>> <tel:%2B94%2071%20809%206732> >>>>> >>>>> http://blog.facilelogin.com >>>>> http://RampartFAQ.com >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> Prabath >>> >>> Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732> >>> >>> http://blog.facilelogin.com >>> http://RampartFAQ.com >>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> Prabath >>> >>> Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732> >>> >>> http://blog.facilelogin.com >>> http://RampartFAQ.com >> >> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732> >> >> http://blog.facilelogin.com >> http://RampartFAQ.com >> >> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732> >> >> http://blog.facilelogin.com >> http://RampartFAQ.com > > > > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com
- [OAUTH-WG] Fwd: New Version Notification for draf… Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] New Version Notification for draft… Eve Maler
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Richard Harrington
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Donald F Coffin
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prabath Siriwardena