Hi Denis, The current text does not imply that you should validate after fetching, it simply states that whenever you are validating a bunch of cached SLTs and encounter an invalid SLT, then you should skip that one and continue with the rest. I don’t think we should say anything other than that and the current sentence does not hinder implementations to validate SLTs on demand / when needed.
Best regards, Christian > On 7. Jul 2025, at 11:57, Denis <denis.ietf=40free...@dmarc.ietf.org> wrote: > > Hi Paul, > > Unfortunately, this change proposal does not address my concern. > > I have the following approach in mind: > > The Relying Party fetches all the Status List Tokens mentioned at the Status > List Aggregation endpoint. It does not verify any signature at this time. > When later on, it needs to verify the status of a Referenced Token, it looks > whether one of these Status List Tokens contains the status of this > Referenced Token. > If it is the case, the Relying Party then validate it, including its > signature. > > If the Relying Party encounters an error while validating this Status List > Token, it does not continue processing the other Status List Tokens, but, > if it is online, it attempts to get the relevant Status List Token. > > I still prefer to remove this sentence. However, if you really want to add a > sentence, I would propose the following: > > If a Relying Party encounters an error while validating a Status List Token > returned from the Status List Aggregation endpoint, if it is online, > it SHOULD attempt to get the relevant Status List Token online. > Denis > >> Hi Denis, >> >> we changed Line 842 to: "If a Relying Party encounters an error while >> validating one of the Status List Tokens returned from the Status List >> Aggregation endpoint, it SHOULD continue processing the other Status List >> Tokens." >> >> This removes any indication whether this is happening during fetching or >> during runtime and hopefully addresses your concerns. >> >> Best, Paul >> >> On 7/4/25 19:24, Denis wrote: >>> Hi Paul, >>> >>> In the Editor's copy, the abbreviation "TSL" does not yet appear. It should >>> be inserted into the document, as well as in the title: >>> >>> Token Status List (TSL) >>> >>> Line 840: >>> >>> - Status List Aggregation is an optional mechanism to retrieve a list of >>> URIs to all Status List Tokens, allowing a Relying Party to fetch all >>> relevant Status List Tokens for a specific type of Referenced Token or >>> Issuer. >>> This mechanism is intended to support fetching and caching mechanisms and >>> allow offline validation of the status of a reference token for a period of >>> time. >>> >>> + Status List Aggregation is an optional mechanism offered by the Issuer to >>> publish a list of one or more Status List Tokens URIs, allowing a Relying >>> Party to fetch Status List Tokens provided by this Issuer. >>> This mechanism is intended to support fetching and caching mechanisms and >>> allow offline validation of the status of a reference token for a period of >>> time. >>> >>> This change is fine for me. >>> >>> Line 842: >>> - If a Relying Party encounters an invalid Status List Token referenced in >>> the response from the Status List Aggregation endpoint, >>> it SHOULD continue processing the other valid Status Lists referenced in >>> the response instead of fully aborting processing and retrying later. >>> >>> + If a Relying Party encounters an error while validating Status List Token >>> referenced in the response from the Status List Aggregation endpoint, >>> it SHOULD continue processing the other valid Status Lists referenced in >>> the response instead of fully aborting processing and retrying later. >>> This change is still not fine for me. >>> >>> As already said, processing options should be left open. Fetching does not >>> imply or mandate any validation. If validation were done at caching time, >>> this would slow down the process. >>> Validation can be done either asynchronously at any time *after* the >>> caching or at the time of use of a TSL. There are many ways to take >>> advantage of the caching and hence recommanding a given way >>> would not be appropriate. For example, the signature of a Status List Token >>> can only be validated when it contains the reference of the Referenced >>> Token. As another example, all Status List Tokens can be validated >>> asynchronously in the background, in particular when a multi-processor >>> environment is available. In this way, if the processing is complete, >>> Status List Tokens from the Status List Aggregation endpoint are already >>> validated. >>> The simplest way to solve this issue is to remove this sentence. >>> >>> Denis >>> >>> >>>> Hi Denis, >>>> >>>> responses inline. We intend to merge this PR by Monday before IETF cutoff. >>>> >>>> On 6/30/25 08:34, Denis wrote: >>>>> Hi Paul, >>>>> >>>>> Three replies are embedded into the text. >>>>>> Our proposed changes are in this PR: >>>>>> https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/295 >>>>>> >>>>>> On 6/20/25 13:06, Paul Bastian wrote: >>>>>>> Hi Denis, >>>>>>> >>>>>>> I've responded to your issues in detail in this Github issue: >>>>>>> https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/294 >>>>>>> >>>>>>> I also copied my answers inline as well. >>>>>>> >>>>>>> A PR will follow later today. >>>>>>> >>>>>>> Best regards, Paul >>>>>>> >>>>>>> On 6/9/25 09:06, Denis wrote: >>>>>>>> Hi Rifaat, >>>>>>>> >>>>>>>> I have 10 comments. >>>>>>>> >>>>>>>> 1) There are still a few vocabulary issues that relate to confusion >>>>>>>> between "Token Status Lists" and "Status List Tokens". >>>>>>>> This is addressed in subsequent comments. >>>>>>>> >>>>>>>> >>>>>>>> 2) The title of the document is "Token Status List". There is no >>>>>>>> single "Token Status List". >>>>>>>> The goal of this document is to allow the retrieval of Status List >>>>>>>> Tokens, where each Status List Token (SLT) >>>>>>>> contains a Token Status List that provides up-to-date status >>>>>>>> information on several Referenced Tokens. >>>>>>>> >>>>>>>> The acronym "SLT" should be introduced in the document, in the same >>>>>>>> way as the acronym "CRL" >>>>>>>> has been introduced for "Certificate Revocation List" (RFC 5280). >>>>>>>> >>>>>>>> The title of this document should rather be: Status List Tokens >>>>>>>> (SLTs) >>>>>>> >>>>>>> The name "Token Status List" of the draft makes sense: >>>>>>> >>>>>>> the naming is similar to Certificate Revocation List - read: Revocation >>>>>>> List for Certificates, here the same: Status List for Token >>>>>>> Token is a very common term in the OAuth ecosystem, similar to >>>>>>> "Certificate", so the naming sequence is exactly the same as CRL >>>>>>> the Status List Token is still its own thing, it's defined in the >>>>>>> section 5 and covers how a Status List structure from Section 4 is >>>>>>> integrty/authenticity-protected, however a Status List Token is usually >>>>>>> not relevant from the high-level outside look >>>>>>> Conclusion: >>>>>>> >>>>>>> I agree that it makes sense to establish an official abbreviation like >>>>>>> CRL >>>>>>> I think that TSL makes more sense >>>>>>> Status List Token should remain as an internal terminology apart from >>>>>>> TSL >>>>> Denis: OK. Let we add the acronym TSL. >>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3) The current text in section 6.1 (Status Claim) is: >>>>>>>> By including a "status" claim in a Referenced Token, the Issuer is >>>>>>>> referencing a mechanism to retrieve status information about this >>>>>>>> Referenced Token. The claim contains members used to reference a >>>>>>>> Status List Token as defined in this specification. Other members >>>>>>>> of >>>>>>>> the "status" object may be defined by other specifications. >>>>>>>> In this specification, only one member of the "status" object is >>>>>>>> defined. >>>>>>>> Taking into account the previous comment, I propose to rephrase >>>>>>>> these sentences as follows: >>>>>>>> By including a "status" claim in a Referenced Token, the Issuer can >>>>>>>> >>>>>>>> indicate in a "status" object, how status information about a >>>>>>>> Referenced Token can be obtained. This specification defines one >>>>>>>> member of the "status" object, called "status_list". Other members >>>>>>>> of >>>>>>>> the "status" object may be defined by other specifications. >>>>>>> Partly accepted >>>>>>>> >>>>>>>> 4) The examples in sections 6.2 and 6.1 are confusing "status lists" >>>>>>>> with "status list tokens". >>>>>>>> >>>>>>>> The current text in section 6.2 ( Referenced Token in JOSE) is: >>>>>>>> The following is a non-normative example of a decoded header and >>>>>>>> payload of a Referenced Token: >>>>>>>> >>>>>>>> { >>>>>>>> "alg": "ES256", >>>>>>>> "kid": "11" >>>>>>>> } >>>>>>>> . >>>>>>>> { >>>>>>>> "status": { >>>>>>>> "status_list": { >>>>>>>> "idx": 0, >>>>>>>> "uri": "https://example.com/statuslists/1"; >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> The uri does not contain "statuslists" (status lists) but "slts" >>>>>>>> (Status List Tokens). >>>>>>>> The uri should be changed into the following way: >>>>>>>> >>>>>>>> "uri": "https://example.com/slts/1"; >>>>>>>> >>>>>>>> The same comment applies to the example on page 22 within section >>>>>>>> 6.3 (Referenced Token in COSE). >>>>>>> The URI is a non-normative example, so I don't believe it is relevant. >>>>>>> If other group members think this is important, we may change this. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 5) The current text in section 9 (Status List Aggregation) is: >>>>>>>> 9. Status List Aggregation >>>>>>>> >>>>>>>> Status List Aggregation is an optional mechanism to retrieve a list >>>>>>>> of URIs to all Status List Tokens, allowing a Relying Party to >>>>>>>> fetch >>>>>>>> all relevant Status List Tokens for a specific type of Referenced >>>>>>>> Token or Issuer. This mechanism is intended to support fetching >>>>>>>> and >>>>>>>> caching mechanisms and allow offline validation of the status of a >>>>>>>> reference token for a period of time. >>>>>>>> The wording "for a specific type of Referenced Token or Issuer" >>>>>>>> should be avoided because the retriever of the SLTs >>>>>>>> has no way to know whether the retrieved SLTs will be about a >>>>>>>> "specific type of Referenced Token", about "all the Referenced Tokens >>>>>>>> issued by that Issuer" or about anything else. Depending upon >>>>>>>> choices made by the Issuer, the retrieved SLTs may help or >>>>>>>> *may not help* the Relying Party, depending upon the context and >>>>>>>> the choices made by the Issuer. >>>>>>>> >>>>>>>> The following rewording is proposed: >>>>>>>> 9. Status List Aggregation >>>>>>>> >>>>>>>> Status List Aggregation is an optional mechanism that allows to take >>>>>>>> advantage of an access to a given Status List Token >>>>>>>> referenced in a Referenced Token to retrieve other Status List Tokens >>>>>>>> published by the same Issuer. >>>>>>>> This feature is intended to support pre-fetching and caching of Status >>>>>>>> List Tokens and allows offline validation of the status >>>>>>>> of further received Reference Tokens for a period of time. >>>>>>> >>>>>>> The Section 9 on Status List Aggregation lists two mechanisms: >>>>>>> >>>>>>> There are two options for a Relying Party to retrieve the Status List >>>>>>> Aggregation. An Issuer MAY support any of these mechanisms: >>>>>>> >>>>>>> Issuer metadata: The Issuer of the Referenced Token publishes an URI >>>>>>> which links to Status List Aggregation, e.g. in publicly available >>>>>>> metadata of an issuance protocol >>>>>>> >>>>>>> Status List Parameter: The Status Issuer includes an additional claim >>>>>>> in the Status List Token that contains the Status List Aggregation URI. >>>>>>> >>>>>>> So while the Relying Party may not know whether an Issuer uses a >>>>>>> particular Status List Aggregation to link all Status Lists or only for >>>>>>> a specific type of Referenced Token, >>>>>>> an Issuer has still the choice to do so, therefore the text is correct >>>>>>> in my opinion. Your proposed text removes functionality that does not >>>>>>> match the rest of Section 9. >>>>>>> >>>>> Denis: Instead of: >>>>> >>>>> Status List Aggregation is an optional mechanism to retrieve a list >>>>> of URIs to all Status List Tokens, allowing a Relying Party to fetch >>>>> all relevant Status List Tokens for a specific type of Referenced >>>>> Token or Issuer. >>>>> >>>>> I propose: >>>>> >>>>> Status List Aggregation is an optional mechanism that allows to take >>>>> advantage of an access to a given Status List Token referenced in >>>>> a Referenced Token to retrieve other Status List Tokens published >>>>> by the same Issuer. >>>>> >>>>> Relying Parties may not know whether an Issuer uses this mechanism >>>>> to allow the retrieval of either all Token Status Lists that it issues >>>>> or >>>>> Token Status Lists specific to some types of Referenced Tokens. >>>>> >>>>> This text does not remove any functionality. >>>>> >>>> I proposed the following changes: >>>> https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/295/commits/4fb1686ce19ea747a388be6d7433c30f5355bee1 >>>>> >>>>> >>>>>>>> >>>>>>>> 6) The text continues with: >>>>>>>> "If a Relying Party encounters an invalid Status List referenced in >>>>>>>> the response from the Status List Aggregation endpoint, it SHOULD >>>>>>>> continue processing the other valid Status Lists referenced in the >>>>>>>> response instead of fully aborting processing and retrying later". >>>>>>>> This sentence is misleading: the Status List Aggregation endpoint >>>>>>>> does not contain "Status Lists" but contains "Status List Tokens". >>>>>>>> If corrected the quoted sentence, the sentence would become: >>>>>>>> If a Relying Party encounters an invalid Status List Token >>>>>>>> referenced >>>>>>>> in the response from the Status List Aggregation endpoint, it >>>>>>>> SHOULD >>>>>>>> continue processing the other valid Status List Tokens referenced >>>>>>>> in >>>>>>>> the response instead of fully aborting processing and retrying >>>>>>>> later. >>>>>>>> However, when fetching the Status List Tokens, the pre-fetching and >>>>>>>> caching mechanism does not *mandate* any "validation mechanism", >>>>>>>> hence the concept of an " invalid Status List" or of an " invalid >>>>>>>> Status List Token" is irrelevant. The goal of this mechanism is to >>>>>>>> allow >>>>>>>> fetching SLTs and to place them into a cache without *necessarily* >>>>>>>> verifying their "validity" at the moment of the retrieval. >>>>>>>> I propose to remove that sentence. >>>>>>> You are correct that it is slightly better to say Status List Token >>>>>>> here. Apart from this, I believe that validation at caching time makes >>>>>>> sense. >>>>>>> There are multiple options ins COSE and JOSE that require fetching >>>>>>> additional resources, like kid for x5u, that wouldn't work >>>>>>> if you only pre-fetch Status List Tokens without validation? >>>>> Denis: Fetching does not imply or mandate any validation. If validation >>>>> were done at caching time, this would slow down the process. >>>>> Validation can be done either asynchronously at any time *after* the >>>>> caching or at the time of use of a TSL. Options should be left open. >>>>> >>>> I proposed the following changes: >>>> https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/295/commits/0e99662ec82b2e26001da537ae8ea19505c35198 >>>>> >>>>> >>>>> End of replies. >>>>> >>>>> PS: Since we will both attend the Global Digital Collaboration Conference >>>>> in Geneva on July 1 rst and 2 nd, >>>>> there will be an opportunity to meet together there. >>>>> >>>>> >>>>> >>>>>>>> >>>>>>>> 7) Section 9.3 (Status List Aggregation in JSON Format) states: >>>>>>>> 9.3. Status List Aggregation in JSON Format >>>>>>>> >>>>>>>> This section defines the structure for a JSON-encoded Status List >>>>>>>> Aggregation: >>>>>>>> >>>>>>>> * status_lists: REQUIRED. JSON array of strings that contains >>>>>>>> URIs >>>>>>>> linking to Status List Tokens. >>>>>>>> >>>>>>>> The Status List Aggregation URI provides a list of Status List >>>>>>>> URIs. >>>>>>>> >>>>>>>> (...) >>>>>>>> >>>>>>>> The following is a non-normative example for media type >>>>>>>> application/ >>>>>>>> json: >>>>>>>> >>>>>>>> { >>>>>>>> "status_lists" : [ >>>>>>>> "https://example.com/statuslists/1";, >>>>>>>> "https://example.com/statuslists/2";, >>>>>>>> "https://example.com/statuslists/3"; >>>>>>>> ] >>>>>>>> } >>>>>>>> >>>>>>>> Given the confusion between "Status Lists" and "Status List >>>>>>>> Tokens", the text from this section should be modified. >>>>>>>> Below is a proposal: >>>>>>>> 9.3. Status List Aggregation in JSON Format >>>>>>>> >>>>>>>> This section defines the structure for a JSON-encoded Status List >>>>>>>> Aggregation: >>>>>>>> >>>>>>>> * status_lists: REQUIRED. JSON array of strings that contains >>>>>>>> URIs >>>>>>>> linking to Status List Tokens. >>>>>>>> >>>>>>>> The Status List Aggregation URI provides a list of Status List >>>>>>>> *Token* URIs. >>>>>>>> >>>>>>>> (...) >>>>>>>> >>>>>>>> The following is a non-normative example for media type >>>>>>>> application/ >>>>>>>> json: >>>>>>>> >>>>>>>> { >>>>>>>> "status_lists" : [ >>>>>>>> "https://example.com/slts/1";, >>>>>>>> "https://example.com/slts/2";, >>>>>>>> "https://example.com/slts/3"; >>>>>>>> ] >>>>>>>> } >>>>>>> Accepted >>>>>>>> >>>>>>>> >>>>>>>> 8) Section 13.1 (Token Lifecycle) states: >>>>>>>> 13.1. Token Lifecycle >>>>>>>> >>>>>>>> The lifetime of a Status List Token depends on the lifetime of its >>>>>>>> Referenced Tokens. Once all Referenced Tokens are expired, the >>>>>>>> Issuer may stop serving the Status List Token. >>>>>>>> >>>>>>>> Referenced Tokens may be regularly re-issued to mitigate the >>>>>>>> linkability of presentations to Relying Parties. In this case, >>>>>>>> every >>>>>>>> re-issued Referenced Token MUST have a fresh Status List entry in >>>>>>>> order to prevent this from becoming a possible source of >>>>>>>> correlation. >>>>>>>> >>>>>>>> Referenced Tokens may also be issued in batches and be presented by >>>>>>>> Holders in a one-time-use policy to avoid linkability. In this >>>>>>>> case, >>>>>>>> every Referenced Token MUST have a dedicated Status List entry and >>>>>>>> MAY be spread across multiple Status List Tokens. Revoking batch- >>>>>>>> issued Referenced Tokens might reveal this correlation later on. >>>>>>>> The use of the sub-title 13.1 "Token Lifecycle " is confusing as it >>>>>>>> can apply either to "Referenced Tokens" or to "Status List Tokens". >>>>>>>> The first sentence applies to "Status List Token Lifecycle" but the >>>>>>>> next sentences apply to linkability issues using indexes contained >>>>>>>> in Status List Tokens. I propose to separate these two cases. >>>>>>>> >>>>>>>> The following text is proposed: >>>>>>>> 13.1. Status List Token Lifecycle >>>>>>>> >>>>>>>> The lifetime of a Status List Token depends on the lifetime of its >>>>>>>> Referenced Tokens. Once all Referenced Tokens from a Status List >>>>>>>> Token >>>>>>>> are expired, the Issuer may stop issuing the Status List Token. >>>>>>>> >>>>>>>> 13.2. Linkability issues using indexes contained in Status List >>>>>>>> Tokens >>>>>>>> >>>>>>>> To mitigate the linkability of presentations of Referenced Tokens >>>>>>>> to >>>>>>>> Relying Parties using the index contained in a Status List Token, >>>>>>>> batches of one-time-use Referenced Tokens should be issued by the >>>>>>>> Issuer and each Referenced Tokens from the batch should only be >>>>>>>> used >>>>>>>> once by the Holder. >>>>>>>> >>>>>>>> For each Referenced Token belonging to a batch of one-time-use >>>>>>>> Referenced Tokens, the indexes in the Status List should not be >>>>>>>> placed into the same Status List and hence into the same Status >>>>>>>> List >>>>>>>> Token, but spread among different Token Status Tokens. In this >>>>>>>> way, >>>>>>>> if the status of a batch of one-time-use Referenced Token changes >>>>>>>> simultaneously, it will be difficult to know whether the Referenced >>>>>>>> >>>>>>>> Tokens belongs to a batch of one-time-use Referenced Tokens and to >>>>>>>> which one. >>>>>>> Accepted to split the sections. >>>>>>>> >>>>>>>> >>>>>>>> 9) There is also an issue about the new IANA entries where the >>>>>>>> "status" claim is defined >>>>>>>> and where it is possible to place underneath the "status_list" >>>>>>>> entry. >>>>>>>> >>>>>>>> The definition of the Claim Name "status" in section 14.1.1 >>>>>>>> includes the following sentence: >>>>>>>> * Claim Description: Reference to a status or validity mechanism >>>>>>>> containing up-to-date status information on the JWT. >>>>>>>> A status or a validity mechanism does not *contain* up-to-date >>>>>>>> status information. >>>>>>>> It *describes* how status information is provided for a given >>>>>>>> Referenced Token. >>>>>>>> >>>>>>>> I suggest to change this sentence into: >>>>>>>> * Claim Description: Reference to a status or validity mechanism >>>>>>>> describing how status information about a Referenced Token can >>>>>>>> be obtained. >>>>>>> Indeed the existing text is not ideal. I propose: "A JSON object >>>>>>> containing a reference to a status mechanism from the JWT Status >>>>>>> Mechanisms Registry." >>>>>>>> >>>>>>>> 10) Section 14.1.2 defines the Claim Name "status_list" >>>>>>>> Claim Name: status_list >>>>>>>> >>>>>>>> * Claim Description: A status list containing up-to-date status >>>>>>>> information on multiple tokens. >>>>>>>> I propose to rephrase it in this way: >>>>>>>> Claim Name: status_list >>>>>>>> >>>>>>>> * Claim Description: A status list contained in a Status List >>>>>>>> Token >>>>>>>> providing up-to-date status information on several Referenced >>>>>>>> Tokens. >>>>>>> Indeed the existing text is not ideal. I propose: "A JSON object >>>>>>> containing up-to-date status information on multiple tokens using the >>>>>>> Token Status List mechanism." >>>>>>>> >>>>>>>> >>>>>>>> Denis >>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> Please, review this version of the document and make sure that your >>>>>>>>> comments, if you had any, were addressed. >>>>>>>>> I will start working on the shepherd write-up in a week or two. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Rifaat >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, May 23, 2025 at 5:05 AM <internet-dra...@ietf.org >>>>>>>>> <mailto:internet-dra...@ietf.org>> wrote: >>>>>>>>>> Internet-Draft draft-ietf-oauth-status-list-11.txt is now available. >>>>>>>>>> It is a >>>>>>>>>> work item of the Web Authorization Protocol (OAUTH) WG of the IETF. >>>>>>>>>> >>>>>>>>>> Title: Token Status List >>>>>>>>>> Authors: Tobias Looker >>>>>>>>>> Paul Bastian >>>>>>>>>> Christian Bormann >>>>>>>>>> Name: draft-ietf-oauth-status-list-11.txt >>>>>>>>>> Pages: 72 >>>>>>>>>> Dates: 2025-05-23 >>>>>>>>>> >>>>>>>>>> Abstract: >>>>>>>>>> >>>>>>>>>> This specification defines a mechanism, data structures and >>>>>>>>>> processing rules for representing the status of tokens secured by >>>>>>>>>> JSON Object Signing and Encryption (JOSE) or CBOR Object Signing >>>>>>>>>> and >>>>>>>>>> Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO >>>>>>>>>> mdoc. It also defines an extension point and a registry for >>>>>>>>>> future >>>>>>>>>> status mechanisms. >>>>>>>>>> >>>>>>>>>> The IETF datatracker status page for this Internet-Draft is: >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ >>>>>>>>>> >>>>>>>>>> There is also an HTML version available at: >>>>>>>>>> https://www.ietf.org/archive/id/draft-ietf-oauth-status-list-11.html >>>>>>>>>> >>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-status-list-11 >>>>>>>>>> >>>>>>>>>> Internet-Drafts are also available by rsync at: >>>>>>>>>> rsync.ietf.org::internet-drafts >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list -- oauth@ietf.org <mailto:oauth@ietf.org> >>>>>>>>>> To unsubscribe send an email to oauth-le...@ietf.org >>>>>>>>>> <mailto:oauth-le...@ietf.org> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list -- oauth@ietf.org <mailto:oauth@ietf.org> >>>>>>>>> To unsubscribe send an email to oauth-le...@ietf.org >>>>>>>>> <mailto:oauth-le...@ietf.org> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list -- oauth@ietf.org <mailto:oauth@ietf.org> >>>>>>>> To unsubscribe send an email to oauth-le...@ietf.org >>>>>>>> <mailto:oauth-le...@ietf.org> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list -- oauth@ietf.org <mailto:oauth@ietf.org> >>>>>> To unsubscribe send an email to oauth-le...@ietf.org >>>>>> <mailto:oauth-le...@ietf.org> >>>>> > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
