Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)

[Denis <[e-mail]>]

Justin,
> Denis,
>
> A lot of what you’re describing below changes the very nature of the 
> roles in the system. The component that manages the consent and issues 
> tokens is, by definition, the AS.

The current charter states: "the artifacts for this work are not 
intended or expected to be backwards-compatible with OAuth 2.0 or OpenID 
Connect".
So we are not bound to OAuth 2.0 nor OpenID Connect. Hence, we do not 
need to stick with all their concepts.

I believe that the user's consent should be given after a dialogue with 
the RS which does not mean that the RS shall capture the user's consent
since it is the duty of the client. When a user selects one operation 
among a choice of operations proposed by the RS, the RS should inform
the client about which attributes it needs to present and from which 
ASs. It is only at this moment that the clients learns which ASs are
adequate. Before this moment, the dialogue *cannot* be handled by an AS. 
Then after the duty of the client is to look for these attributes and
to get them from one or more ASs. ASs are all equal. There is no single 
AS with which the user shall be bound or have a particular relationship

Managing the authorization (and the user's consent) at the RS is simple: 
I have proposed a way to do it (and FIDO U2F is even included).

Managing the authorization at the AS would mandate a close 
synchronization between the RS and all the ASs with which it has a 
relationship.
There would be the need to define a synch. protocol and it is much 
simpler to avoid to use such a protocol and thus not to define it.
"Out-of-bands" means for such a synchronisation would not be a better 
solution. But the major issue by managing the user's consent at the AS
is to allow the AS to act as Big Brother.

A copy and paste from a document published under the "Digital Europe for 
All" (DE4A) project :

    The privacy principle requires that the private life, the home and
    the communications of each citizen
    are respected and that no personal data are gathered without a
    legitimate reason and purpose.

    Data protection and privacy should (as far as possible) be *achieved
    by design*, i.e. be embedded in the
    technical solutions and services in a way that misuse or
    illegitimate access is made impossible or at
    least very difficult through the technical approach itself, and
    *without having to rely on organisational **
    **measures or solely on legal measures to guarantee the compliance*.

    Main sources for this principle: CFREU, GDPR, eIDAS, eGov Action
    Plan, EIF, Tallinn Declaration, and
    SDGR.

> The user shouldn’t ever have to interact directly with the RS, since 
> the RS is, by definition, an API that is called by software, not an 
> interactive component.
>
> But it’s important to note that these are only :roles: to be played 
> and not strictly speaking separate pieces of software, and that these 
> roles can be combined and split in a variety of ways. For instance, in 
> what you’re talking about below, instead of saying that it’s the RS 
> that manages the consent, what if you saw it as the functionality of 
> the AS that’s been split between two components: one 
> privacy-preserving element that issues tokens, and another that deals 
> with interaction and consent. This is already a pattern that some in 
> the WG have expressed interest in supporting with GNAP, and the core 
> charter tenet of separating the interaction from the delegation 
> channels is something that could help there.
>
> Would it be possible to look at your use case in this different light?

I could see the RS (i.e. not the AS) split into two components: an API 
and an MMI to manage the choices and the consent of the user.
This looks artificial but would it help ?

Denis

> It’s always possible that we need to re-cast some of these roles, and 
> that’s been done before: in OAuth 2 we defined the AS and RS roles 
> separately, even though they can always be deployed together anyway. 
> So with that it’s possible that there are other distinct pieces here 
> that are working together that we need to tease out, but that’s 
> something for the WG to figure out. We can always decide to separate 
> out the parts and allow them to be recombined in deployment, But I do 
> not think it is helpful to redefine the existing roles, especially by 
> moving key facets from one existing role to another.
>
>  — Justin
>
>> On Jul 7, 2020, at 8:43 AM, Denis <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Hi Roman,
>>> Hi Denis!
>>> Thanks for the feedback and for repeating your review on the revised 
>>> text.  More inline …
>>> *From:*iesg<[e-mail]>*On Behalf Of*Denis
>>> *Sent:*Monday, July 6, 2020 10:55 AM
>>> *To:*[e-mail]
>>> *Cc:*[e-mail]
>>> *Subject:*Re: [Txauth] WG Review: Grant Negotiation and 
>>> Authorization Protocol (gnap)
>>> Since it is today the last day to send back comments, you will find 
>>> hereafter my comments on the last charter version-05.
>>
>> BTW, I sent an email yesterday evening with the subject:*Support of 
>> FIDO*and data minimization by RSs, where I indicated that the charter 
>> should
>> mention FIDO U2F so that it should be possible to logon to a RS using 
>> either FIDO or by presenting one (or more) access tokens from one (or 
>> more) AS.
>>
>> The original email is here 
>> :https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/
>>
>>>
>>>     charter-ietf-gnap-00-05
>>>
>>> This group is chartered to develop a fine-grained delegation 
>>> protocol for authorization, API access, user identifiers, and 
>>> identity assertions.
>>> [Denis] Fine.
>>> The protocol will also allow the client to present unverified 
>>> identifiers and verifiable assertions to the AS as part of its request.
>>> [Denis] This sentence is too vague because "as part of its request" 
>>> is not explicit enough. If it means  "as part as an access token 
>>> request"
>>> this should be explicitly said. If, it is not the case, then it 
>>> should be clearly explained. The AS should know as little as 
>>> possible (including nothing)
>>> about what the client is doing.
>>> [Roman] The “request” here is the “access token request”.  That can 
>>> be made clearer.
>>
>> This would be appreciated.
>>
>>> This protocol will allow an authorizing party to delegate access to 
>>> client software through an authorization server.
>>> [Denis] The word "*privacy*" is still missing in the charter. 
>>> "Delegating access to client software through an authorization server"
>>> is negating the fact that the user's privacy will ever be 
>>> considered. IMHO, I believe that a RS may delegate some operation to 
>>> another RS,
>>> but I don't believe that an AS should be concerned by any form of 
>>> delegation, otherwise it would have the ability to act as "Big Brother".
>>> OAuth has not been constructed taking into consideration the user's 
>>> privacy. The major difference with it should be that GNAP has been
>>> constructed along "*privacy by design*" principles.
>>> [Roman]  I don’t exactly follow how considerations for privacy are 
>>> being negated.  Above and beyond use-case specific considerations 
>>> that would be defined later, RFC6973 is the IETF consensus design 
>>> guidance that will guide the privacy threats and mitigations of the 
>>> work.  What design guidance would you recommend that the WG should 
>>> consider that aren’t captured in RFC6973?
>>
>> I believe my message is quite clear : If the AS is handling the 
>> delegation process, it will know what the client is doing or where it 
>> is going.
>> On the contrary, if the RS is handling the delegation process, the AS 
>> will be unable to know what the client is doing. In addition, an 
>> AS-centric
>> architecture would not be scalable and would need a lot of 
>> synchronizations between ASs and RSs. The user consent should be 
>> handled by the RS
>> and not by the AS. When a RS is unable to provide the service, it is 
>> best placed to tell directly to the client what it could do next.
>>
>> RFC 6973 is very good document. Section 7.1 states:
>>
>>           b.  Data. What information does the protocol expose about 
>> individuals, their devices, and/or their device usage (other than the 
>> identifiers discussed in (a))?
>>
>> Data includes both the operation and the data associated with the 
>> operation. An AS should be kept ignorant of both the operation and 
>> the data associated with the operation.
>>
>>     c.  Observers.  (...) Are there ways for protocol implementers
>>     to  choose to limit the information shared with each entity?
>>
>> If theses guidances were followed, the proposed architecture would 
>> not be AS-centric.
>>
>>> It will *expand* upon the uses cases currently supported by OAuth 
>>> 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support 
>>> authorizations
>>> scoped as narrowly as a single transaction, provide a clear 
>>> framework for interaction among all parties involved in the protocol 
>>> flow, and remove
>>> unnecessary dependence on a browser or user-agent for coordinating 
>>> interactions.
>>> [Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. 
>>> Some existing uses cases (i.e. "*non-expanded"* use cases) should be 
>>> supported
>>> differently from OAuth 2.0 and OpenID Connect, in particular to 
>>> support the user's privacy.
>>> [Roman] I’d want to hear others on this rescoping.  Building upon 
>>> the use cases of OAuth 2.0 and OpenID Connect has been core, 
>>> consensus-validated tenant for some time now.
>>> The delegation process will be acted upon by multiple parties in the 
>>> protocol, each performing a specific role. The protocol will 
>>> decouple the channels used
>>> by the protocol participants to communicate from the delegation 
>>> channel, which happens directly between the client and the 
>>> authorization server (in contrast
>>> with OAuth 2.0, which is initiated by the client redirecting the 
>>> user’s browser).
>>> [Denis] Here again, the delegation process, if any, should be 
>>> handled by RSs and not by ASs.
>>> The term "delegation channel" is being used but it is left 
>>> undefined. It is not understandable.
>>> [Roman] This sentence was just added into -05 address Security AD 
>>> feedback.  In this case, it was made to distinguish between in-band 
>>> signaling and the new purpose-to-be-built channel.
>>
>> Since delegation should not be handled by the AS, a delegation 
>> channel should not exist.
>>
>>> The protocol will include a means of specifying how the user can 
>>> potentially be involved in an interactive fashion during the 
>>> delegation process.
>>> The client and Authorization Server (AS) will use these interaction 
>>> mechanisms to involve the user, as necessary, to make authorization 
>>> decisions.
>>> [Denis] Here again, the delegation process, if any, should be 
>>> handled by RSs and not by ASs. The AS should know as little as 
>>> possible (including nothing)
>>> about what the client is doing.
>>> [Roman] Understood – as I understand it, you have concern with the 
>>> scope of the AS behavior.  I’d be interesting in hearing additional 
>>> support for this rescoping.
>>> This decoupling avoids many of the security concerns and technical 
>>> challenges of OAuth 2.0 and provides a non-invasive path for 
>>> supporting future types
>>> of clients and interaction channels.
>>> [Denis] This is not understandable to me. Is such a sentence really 
>>> needed in a charter ?
>>> [Roman] Can someone on the TxAuth mailing list remind us on why this 
>>> sentence is here?  With a fresh read, I also can’t remember why we 
>>> need it.
>>> The group will define interoperability for this protocol between 
>>> different parties, including
>>> -client and authorization server;
>>> -client and resource server; and
>>>      -      authorization server and resource server.
>>> [Denis] In order to support the user's privacy, there should be no 
>>> interaction at all between an authorization server and a resource 
>>> server
>>> /at the time of a client request/.
>>> The group will seek to minimize assumptions about the form of client 
>>> applications, allowing for:
>>> -Fine-grained specification of access
>>> -Approval of AS attestation to identifiers and other identity claims
>>> -Approval of access to multiple resources and APIs in a single 
>>> interaction
>>> -Multiple access tokens in a single request and response
>>> -AS-directed dispatch of access tokens to the appropriate RS
>>> [Denis] As-directed dispatch does not allow to support the user's 
>>> privacy. However, RS-directed dispatch allows to support the user's 
>>> privacy.
>>> It should be explicitly mentioned.
>>> [Roman] As above (per the AS vs. RS behavior)
>>> -Separation between the party authorizing access and the party 
>>> operating the client requesting access
>>> [Denis] It is questionable whether such a separation would be really 
>>> beneficial. In doubt, this item should be removed.
>>> [Roman] Could you say more on why this flexibility wouldn’t be worth 
>>> it?
>>
>> Except for added complexity, there is no need to have separate 
>> channels. It is simpler to send the access token in addition to the data
>> and, for additional security, to sign the data using a private key 
>> corresponding to a public key present in the access token.
>>
>>> The group will define extension points for this protocol to allow 
>>> for flexibility in areas including:
>>> Cryptographic agility for keys, message signatures, and proof of 
>>> possession
>>> -User interaction mechanisms including web and non-web methods
>>> -Mechanisms for conveying user, software, organization, and other 
>>> information used in authorization decisions
>>> -Mechanisms for presenting tokens to resource servers and binding 
>>> resource requests to tokens and associated cryptographic keys
>>> Optimized inclusion of additional information (including identifiers 
>>> and identity assertions) through the delegation process
>>> Additionally, the group will provide mechanisms for management of 
>>> the protocol lifecycle including:
>>> -Discovery of the authorization server
>>> -Revocation of active tokens
>>> Data model for granted access and mechanisms for the AS and RS to 
>>> communicate the granted access model
>>> [Denis] While it is the duty for the RS to communicate the granted 
>>> access model to the client /at the appropriate instant of time/,
>>> the AS should be kept fully ignorant of it.
>>> Although the artifacts for this work are not intended or expected to 
>>> be backwards-compatible with OAuth 2.0 or OpenID Connect,
>>> the group will attempt to simplify migrating from OAuth 2.0 and 
>>> OpenID Connect to the new protocol where possible.
>>> This group is not chartered to develop extensions to OAuth 2.0, and 
>>> as such will focus on new technological solutions not necessarily
>>> compatible with OAuth 2.0. Functionality that builds directly on 
>>> OAuth 2.0 will be directed to the OAuth Working Group, including
>>> functionality back-ported from the protocol developed here to OAuth 2.0.
>>> The group is chartered to develop mechanisms for applying 
>>> cryptographic methods, such as JOSE and COSE, to the delegation 
>>> process.
>>> This group is not chartered to develop new cryptographic methods.
>>> The group is chartered to develop mechanisms for conveying identity 
>>> information within the protocol including existing identifiers
>>> (such as email addresses, phone numbers, usernames, and subject 
>>> identifiers) and assertions (such as OpenID Connect ID Tokens,
>>> SAML Assertions, and Verifiable Credentials). The group is not 
>>> chartered to develop new formats for identifiers or assertions, nor 
>>> is the group
>>> chartered to develop schemas for user information, profiles, or 
>>> other identity attributes, unless a viable existing format is not 
>>> available.
>>> The initial work will focus on using HTTPS for communication between 
>>> the client and the authorization server, taking advantage
>>> of optimization features of HTTP/2 and HTTP/3 where possible, and 
>>> will strive to enable simple mapping to other protocols such as COAP
>>> when doing so does not conflict with the primary focus.
>>> Milestones to include:
>>> -Core delegation protocol
>>> [Denis] Before defining a "Core delegation protocol", a simple 
>>> client server-protocol involving the presentation of several access 
>>> tokens to one RS should be defined.
>>> Privacy principles should be applied when defining the protocol. 
>>> Then after, a delegation mechanism allowing one RS to forward an 
>>> operation to another RS should be defined.
>>> -Key presentation mechanism bindings to the core protocol including 
>>> TLS, detached HTTP signature, and embedded HTTP signatures
>>> [Denis] Bindings to TLS are now deprecated, why should they be 
>>> maintained ?
>>> Signatures may be needed but they do not necessarily need to be 
>>> "detached HTTP signature, and embedded HTTP signatures".
>>> This item should be either removed or reworded.
>>> [Roman] Noted.  I’d want to hear others on this rescoping.
>>
>> As explained above, it is possible to sign the data using a private 
>> key corresponding to a public key present in the access token.
>>
>>> -Conveyance mechanisms for identifiers and assertions
>>> -Guidelines for use of protocol extension points (if needed)
>>>      -    Guidelines on migration paths, implementation, and operations
>>> [Denis] The above three lines are rather mysterious.
>>> [Roman] The guidelines on migration paths came from the initial IESG 
>>> review in order to have a named activity to action the design goal 
>>> of “… the group will attempt to simplify migrating from OAuth 2.0 
>>> and OpenID Connect to the new protocol where possible” a bit earlier 
>>> in the text.
>>> Where possible, the group will seek to make use of tools to guide 
>>> and inform the standardization process including formal analysis,
>>> architecture documents, and use case documents. These artifacts will 
>>> not be considered as working group milestones or deliverables.
>>> The working group will cooperate and coordinate with other IETF WGs 
>>> such as OAUTH, and work with external organizations,
>>> such as the OpenID Foundation, as appropriate.
>>> [Denis] The charter should be shorter.
>>> [Roman] Definitely.  Nevertheless, we have the current text through 
>>> rough consensus process achieved from two BoFs and multiple mailing 
>>> list consensus calls.
>>
>> In a previous post, I proposed a much shorter text.
>>
>> Denis
>>
>>> Regards,
>>> Roman
>>> /Denis
>>>
>>>     A new IETF WG has been proposed in the Security Area. The IESG has not made
>>>
>>>     any determination yet. The following draft charter was submitted, and is
>>>
>>>     provided for informational purposes only. Please send your comments to the
>>>
>>>     IESG mailing list ([e-mail]  <mailto:[e-mail]>)*by 2020-07-06*.
>>>
>>>     Grant Negotiation and Authorization Protocol (gnap)
>>>
>>>     -----------------------------------------------------------------------
>>>
>>>     Current status: Proposed WG
>>>
>>>     Chairs:
>>>
>>>        Yaron Sheffer<[e-mail]>  <mailto:[e-mail]>
>>>
>>>        Leif Johansson<[e-mail]>  <mailto:[e-mail]>
>>>
>>>     Assigned Area Director:
>>>
>>>        Roman Danyliw<[e-mail]>  <mailto:[e-mail]>
>>>
>>>     Security Area Directors:
>>>
>>>        Benjamin Kaduk<[e-mail]>  <mailto:[e-mail]>
>>>
>>>        Roman Danyliw<[e-mail]>  <mailto:[e-mail]>
>>>
>>>     Mailing list:
>>>
>>>        Address:[e-mail]  <mailto:[e-mail]>
>>>
>>>        To subscribe:​https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>        Archive:https://mailarchive.ietf.org/arch/browse/txauth/
>>>
>>>     Group page:https://datatracker.ietf.org/group/gnap/
>>>
>>>     Charter:https://datatracker.ietf.org/doc/charter-ietf-gnap/
>>>
>>>     This group is chartered to develop a fine-grained delegation protocol for
>>>
>>>     authorization and API access, as well as requesting and providing user
>>>
>>>     identifiers and claims. This protocol will allow an authorizing party to
>>>
>>>     delegate access to client software through an authorization server. It will
>>>
>>>     expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect
>>>
>>>     (itself an extension of OAuth 2.0) to support authorizations scoped as
>>>
>>>     narrowly as a single transaction, provide a clear framework for interaction
>>>
>>>     among all parties involved in the protocol flow, and remove unnecessary
>>>
>>>     dependence on a browser or user-agent for coordinating interactions.
>>>
>>>     The delegation process will be acted upon by multiple parties in the protocol,
>>>
>>>     each performing a specific role. The protocol will decouple the interaction
>>>
>>>     channels, such as the end user’s browser, from the delegation channel, which
>>>
>>>     happens directly between the client and the authorization server (in contrast
>>>
>>>     with OAuth 2.0, which is initiated by the client redirecting the user’s
>>>
>>>     browser). The protocol will include a means of specifying how the user can
>>>
>>>     potentially be involved in an interactive fashion during the delegation
>>>
>>>     process. The client and Authorization Server (AS) will use these interaction
>>>
>>>     mechanisms to involve the user, as necessary, to make authorization decisions.
>>>
>>>     This decoupling avoids many of the security concerns and technical challenges
>>>
>>>     of OAuth 2.0 and provides a non-invasive path for supporting future types of
>>>
>>>     clients and interaction channels.
>>>
>>>     The group will define interoperability for this protocol between different
>>>
>>>     parties, including
>>>
>>>       - client and authorization server;
>>>
>>>       - client and resource server; and
>>>
>>>       - authorization server and resource server.
>>>
>>>     The group will seek to minimize assumptions about the form of client
>>>
>>>     applications, allowing for:
>>>
>>>     - Fine-grained specification of access
>>>
>>>     - Approval of AS attestation to identifiers and other identity claims
>>>
>>>     - Approval of access to multiple resources and APIs in a single interaction
>>>
>>>     - Support for multiple access tokens in a single request and response
>>>
>>>     - Support for directed, audience-restricted access tokens
>>>
>>>     - Separation between the party authorizing access and the party operating the
>>>
>>>     client requesting access
>>>
>>>     The group will define extension points for this protocol to allow for
>>>
>>>     flexibility in areas including:
>>>
>>>     - Cryptographic agility for keys, message signatures, and proof of possession
>>>
>>>     - User interaction mechanisms including web and non-web methods
>>>
>>>     - Mechanisms for conveying user, software, organization, and other
>>>
>>>     information used in authorization decisions
>>>
>>>     - Mechanisms for presenting tokens to resource servers and binding resource
>>>
>>>     requests to tokens and associated cryptographic keys
>>>
>>>     - Optimized inclusion of additional information (including identifiers and
>>>
>>>     identity assertions) through the delegation process
>>>
>>>     Additionally, the group will provide mechanisms for management of the protocol
>>>
>>>     lifecycle including:
>>>
>>>     - Discovery of the authorization server
>>>
>>>     - Revocation of active tokens
>>>
>>>     - Mechanisms for the AS and RS to communicate the access granted by an access
>>>
>>>     token
>>>
>>>     Although the artifacts for this work are not intended or expected to be
>>>
>>>     backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt
>>>
>>>     to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol
>>>
>>>     where possible.
>>>
>>>     This group is not chartered to develop extensions to OAuth 2.0, and as such
>>>
>>>     will focus on new technological solutions not necessarily compatible with
>>>
>>>     OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed
>>>
>>>     to the OAuth Working Group, including functionality back-ported from the
>>>
>>>     protocol developed here to OAuth 2.0.
>>>
>>>     The group is chartered to develop mechanisms for applying cryptographic
>>>
>>>     methods, such as JOSE and COSE, to the delegation process. This group is not
>>>
>>>     chartered to develop new cryptographic methods.
>>>
>>>     The group is chartered to develop mechanisms for conveying identity
>>>
>>>     information within the protocol including existing identifiers (such as email
>>>
>>>     addresses, phone numbers, usernames, and subject identifiers) and assertions
>>>
>>>     (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
>>>
>>>     Credentials). The group is not chartered to develop new formats for
>>>
>>>     identifiers or assertions, nor is the group chartered to develop schemas for
>>>
>>>     user information, profiles, or other identity attributes, unless a viable
>>>
>>>     existing format is not available.
>>>
>>>     The initial work will focus on using HTTPS for communication between the
>>>
>>>     client and the authorization server, taking advantage of optimization
>>>
>>>     features of HTTP/2 and HTTP/3 where possible, and will strive to enable
>>>
>>>     simple mapping to other protocols such as COAP when doing so does not
>>>
>>>     conflict with the primary focus.
>>>
>>>     Milestones to include:
>>>
>>>     - Core delegation protocol
>>>
>>>     - Key presentation mechanism bindings to the core protocol including TLS,
>>>
>>>     detached HTTP signature, and embedded HTTP signatures
>>>
>>>     - Conveyance mechanisms for identifiers and assertions
>>>
>>>     - Guidelines for use of protocol extension points
>>>
>>>     - (if needed) Guidelines on migration paths, implementation, and operations
>>>
>>>     Where possible, the group will seek to make use of tools to guide and inform
>>>
>>>     the standardization process including formal analysis, architecture documents,
>>>
>>>     and use case documents. These artifacts will not be considered as working
>>>
>>>     group milestones or deliverables.
>>>
>>>     The working group will cooperate and coordinate with other IETF WGs such as
>>>
>>>     OAUTH, and work with external organizations, such as the OpenID Foundation,
>>>
>>>     as appropriate.
>>>
>>>     Milestones:
>>>
>>>        Jul 2021 - Core delegation protocol in WGLC
>>>
>>>        Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to
>>>
>>>        WGLC
>>>
>>>        Oct 2021 - Key presentation mechanism binding to the core protocol,
>>>
>>>        detached HTTP signatures, to WGLC
>>>
>>>        Oct 2021 - Key presentation mechanism binding to the core protocol,
>>>
>>>        embedded HTTP signature, to WGLC
>>>
>>>        Dec 2021 - Guidelines for use of protocol extension points to WGLC
>>>
>>>        Feb 2022 - Guidelines on migration paths, implementation, and operations to
>>>
>>>         WGLC
>>>
>>
>> --
>> Txauth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth
>