One thing we have talked about is having the RPC handle editorial
class 1 reports, and we can discuss that again if we like. Should we
do that, it might make sense to have a separate handling code for
those that the RPC resolves.
Barry
On Mon, Jun 1, 2020 at 9:16 AM Barry Leiba wrote:
>
&
That's what the "technical" vs "editorial" distinction is supposed to be for.
Barry
On Mon, Jun 1, 2020 at 8:27 AM Rob Wilton (rwilton)
wrote:
>
>
>
> > -Original Message-
> > From: iesg On Behalf Of Benjamin Kaduk
> > Sent: 31 May 2020 05:09
> > To: Pete Resnick
> > Cc: m...@microsoft
> But https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/,
> in particular:
>
> Only errors that could cause implementation or deployment problems or
> significant confusion should be Verified.
> Things that are clearly wrong but could not cause an implementation or
> deploy
a bit hesitant to make a change
>> like that at this stage. I guess I'd be looking for a little more buy-in
>> from folks first. Though it's not actually a functional breaking change. So
>> maybe okay to just go with.
>>
>> On Wed, Sep 4, 2019 at 2:54
> Yeah, with query parameters lacking the hierarchical semantics that the path
> component has, it is much less clear. In fact, an earlier revision of the
> draft forbid the query part as I was trying to avoid the ambiguity that it
> brings. But there were enough folks with some use case for it
>> AH. I read later in the document and figured out my problem: I think it
>> would
>> help if you hyphenate "audience-restrict" (and "audience-restricted" later).
>> No?
>
> Yes? Short of Adam Roach stepping in here to teach me more about proper use
> of hyphens [1], I
> think that would be hel
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
gt;
>> That works for me.
>>
>> On Sat, Jul 20, 2019 at 10:28 PM Benjamin Kaduk wrote:
>>>
>>> On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote:
>>> > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba
>>> > wrote:
>>> &g
>> and I trust the authors and responsible AD to do the right thing.
>
> I always endeavor to do the right thing.
You do; hence, the trust. :-)
And thanks for the quick responses.
>> — Section 1.1 —
>> Given the extensive discussion of impersonation here, what strikes me as
>> missing is pointin
> I think I was reading this as "if the server can't fulfil the exact request
> as given, it returns an error and says "try again slightly differently".
Yes, I'm sure that's what's meant. I'm asking that that be clarified,
because I have seen problems in implementation of other specifications
whe
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-token-exchange-18: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-jwt-bcp-06: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
> Thanks for your review. Please see my responses inline below...
And thanks for your responses. All OK, including the alternatives you
gave to my suggestions. Thanks, as always, for addressing my
comments.
Barry
___
OAuth mailing list
OAuth@ietf.or
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-proof-of-possession-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
> Now, as to the spec change is concerned, I agree with John that it is not
> required.
>
> However, a Best practice document would probably help the developers.
That's exactly what I had in mind -- no spec change, but something (or
some things) to help guide developers into do the right thing,
se
> In JWS we used ASCII(string) to indicate that the output is a sequence of
> octets, strings are not necessarily 8 characters bits and may have null
> termination etc.
>
> However as Brian states other changes may have removed the need for that.
>
> I admit saying "where STRING is a sequence of ze
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-spop-14: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-introspection-10: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
>> 1. Why is GET an optimization? It has privacy disadvantages, and I
>> don't see any advantages.
>>
>> 2. This "tight coupling" thing is something that I think weakens the
>> interoperability of the OAuth protocol in general, and I've never
>> liked it. In this case, in particular, I don't see
> Hi, Hannes, and thanks for clearing this bit up.
>
>>>4) The attacker (via the installed app) is able to observe responses
>>> from the authorization endpoint. As a more sophisticated attack
>>> scenario the attacker is also able to observe requests (in
>>> addition to resp
Hi, Hannes, and thanks for clearing this bit up.
>>4) The attacker (via the installed app) is able to observe responses
>> from the authorization endpoint. As a more sophisticated attack
>> scenario the attacker is also able to observe requests (in
>> addition to responses)
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-spop-12: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
vailable to an attacker by removing PKCE entirely from the
> request.
>
> Unfortunately this week is CIS for me and I am having a hard time keeping up
> with email.
>
> Let me know what you think.
>
> I agree that we want to direct developers to S256 as the preference, bu
Hi, Nat, and thanks for the reply.
>> How does "plain" do anything at all to mitigate this attack? Wouldn't
>> anyone who could snag the grant also be able to snag the code verifier as
>> well? Why is "plain" even here?
>
> You have to understand that this spec deals with a scenario that the
> c
Hi, Justin. Thanks for the response and discussion.
>> -- Section 2 --
>>
>>The introspection endpoint MUST be protected by a transport-layer
>>security mechanism as described in Section 4.
>>
>> I know what it means for a communication path to be protected by TLS, but
>> I don't know wha
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-spop-12: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
>> -- Section 3.1 --
>> I'd REALLY like to see us stop trying to tell IANA how to handle review
>> by designated experts. This should be re-cast as instructions to the DE
>> (to make sure that the mailing list is consulted), and IANA should be
>> left to handle the expert review with their existin
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-introspection-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
>
>
>>Assertions used in the protocol exchanges defined by this
>>specification MUST always be protected against tampering using a
>>digital signature or a keyed message digest applied by the issuer.
>>
>> Why is that? Aren't you using assertions over a protected channel (as
>> required
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-assertions-17: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
> At Stephen Farrell's request, I'm responding with "> " line prefixes
> on previous thread content.
Yeh, Outlook (and certain other clients, such as Lotus Notes) are
particularly bad at cooperating with the Internet-style quoting, and
it can get to be quite a mess as people with all different kin
>> Any idea, on the two Assertion Documents, if there is or will be any
>> feedback from the IESG and, if so, what form it might take?
>
> I'm sorry that I haven't been able to get to reviewing this yet --
> I've had a bunch of pre-IETF travel, in addition to preparing for the
> meeting. I aim to
> Any idea, on the two Assertion Documents, if there is or will be any
> feedback from the IESG and, if so, what form it might take?
I'm sorry that I haven't been able to get to reviewing this yet --
I've had a bunch of pre-IETF travel, in addition to preparing for the
meeting. I aim to have a lo
> As I recall, the argument was that without this, someone could just keep
> fishing at the
> token revocation endpoint for valid tokens. Though thinking about it now,
> even if you
> did get a "token was valid" response, the token wouldn't be valid anymore and
> it wouldn't
> do you much good.
> Sergey has the correct interpretation -- it's to prevent a class of oracle
> attacks.
> Think of it this way, if you go to revoke a token, and the token wasn't there
> in the
> first place, the end result is the same: the token's not there when you're
> done. So
> it's a 200 because the result
> The eventbrite page for people wanting to attend the openID Connect session
> prior to IETF86 is now available at:
> http://openid-ietf-86.eventbrite.com/
That page says this:
OpenID Meeting at IETF 86
The OpenID Foundation
Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT)
Orlan
> I can tell you that I don't think Barry and I are asking for
> contradictory things. They are different, but not contradictory,
> and have the same goal (interop). I believe Barry would agree
> with that.
>
> Saying that field X is MTI can be entirely consistent with
> defining a protocol that al
>
> "Dynamically declaring," in what sense? Where are those mechanisms
> documented?
>
> ** **
>
> Many of them are documented in draft-ietf-oauth-dyn-reg.
>
> ** **
>
> One profile (an outer doll J) that enables fully interoperable
> implementations is documented in draft-hardjono-oauth-u
>
> It seems like the scope of your criticism has more to do with RFC 6749 &
> RFC 6750 overall, than the assertions drafts themselves.
>
No, and I'm sorry if it came across that way. I mentioned the token-type
issue only by way of background. As it happens, I do think it was a
mistake to publis
I'll get to John's message later, after I digest it more. I can reply to
this one now.
please explain how you and I can each write applications to that?
>
> **
>
> ** **
>
> You can write applications to that by having the profile chain end, and
> with the contents of the Audience field being com
OK, I have some time to respond to this on a real computer.
Let's look at the general mechanism that oauth provides, using one use case:
A client asks an authorization server for authorization to do something.
The authorization server responds with an authorization token, which
the client is requi
> Corrected Text
> --
> Resource owners cannot revoke access to an individual third party without
> revoking access
> to all third parties, and must do so by changing their password.
>
> Notes
> -
> The text was originally "their" but changed to "the third party's" between
> the l
> [ I was nosing around and noticed this relatively recent decision, it didn't
> appear to have been fwd'd to these lists. fyi/fwiw... ]
...
> The IESG has no problem with the publication of 'SCS: Secure Cookie
> Sessions for HTTP' as an
> Informational RFC.
>
> The IESG has concluded that this wo
the ISE at .
General discussion of the document on these lists or the saag list will
likely not get to the authors or the ISE.
Barry Leiba, Applications AD
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
> Particularly, the authors are looking for advice with the use of the example
> URLs. Following the guidance of RFC 2606,
>
> we have used “example” as the top level domain name (e.g., example.com).
> This may mislead readers into thinking that all URLs belong to the same
> organization. A general
> Eran Hammer has decided to step down as Editor of the OAuth Core
> specification. I would like to personally thank Eran for all his years
> of hard work and effort to the draft as well as to the working group at
> large.
As former chair, I want to add my thanks. Eran has done a *lot* of
work o
> 1. The relation between this document, OAuth 1.0 (RFC 5849) and OAuth
> 2.0 is not clear. In the Introduction we find:
>
>This document gives additional security considerations for OAuth,
>beyond those in the OAuth specification, based on a comprehensive
>threat model for the OAuth 2.
>
> Per http://www.ietf.org/mail-archive/web/oauth/current/msg09407.html
> and barring any objections, I'd ask the Chairs to give the AD the okay
> to move this to LC.
The irresponsible AD from Apps thinks this s a fine idea, and that this
version is ready.
Barry
>>> Have Section 3 note that certain classes might create new
>>> sub-registries for what goes under them, if necessary.
>>
>> I honestly don't understand the push to have additional registries under
>> urn:ietf:params:oauth?
>
> I agree that one registry is sufficient. The number of registrations
>> Stephen:
>> Yeah, I'm not sure Standards Track is needed.
>
> On this bit: I personally don't care, except that we don't have to do it twice
> because someone later on thinks the opposite and wins that argument, which
> I'd rather not have at all (My one-track mind:-) Doing the 4 week last call
This one's mostly there. As Mike and Hannes are discussing, the WG
needs to sort out exactly what goes under "oauth" here.
Here's a suggestion:
Have Section 3 specify that what comes after "oauth" are one or more
tokens, delimited by ":".
Have Section 3 create the registry for the first-level tok
>> (1) Why Informational? Everything else at that level seems to
>> be specified in a standards track or BCP level RFC, and IETF
>> Consensus is required. [1] I think you have to do this as
>> standards track. Did I miss something?
>>
> Standards Track is OK.
Stephen:
Yeah, I'm not sure Standards
I'd like to see the new version, since there appear to be a bunch of
changes, but first here are some issues that I don't think have been
brought up yet:
The URN registration stuff seems very incompletely baked. The title
of 5.1 correctly says it's registering a sub-namespace, but the text
incorr
> Things like "%x21 / %x23-5B / %x5D-7E" should be named once and re-used.
An excellent suggestion, and one I hope is adopted.
Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
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,
Phil said...
> **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
> As far as I know, none of my concerns were incorporated.
Correct, and I will take care of that (or try to) in my shepherd review.
Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
> Off list.
Or not so much off list. He-he.
b
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Off list.
> It would be great if people could just reply stating which they like best.
כן
Sometimes, one just has to whack people over the head.
b
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Oh, and...
> 4. MAC Token (TBD)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/
I believe that in Eran's last communication about this he said that he
does, after all, have the time and inclination to finish it, and would
like to.
b
__
Looks good to me. One note:
> 2. OAuth Threats Document (Torsten)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/
I have been terribly remiss on this, so here's the thing:
- We have completed WGLC on this, and are awaiting my shepherd review
(which will include a recommendat
> I am sorry, but with this language this is a different spec with
> different compliance profiles and without supplying enough guidance
> for creating interoperable server implementations for common
> deployment models.
As I read this thread, I see two things come out clearly:
1. Eran didn't int
> OAuth Chairs,
Changed CC address; please see my list message:
http://www.ietf.org/mail-archive/web/oauth/current/msg08531.html
> Do you approve of posting an updated Bearer spec as below, assuming the
> working group does not object by mid-day Monday?
Yes, that makes sense.
Barry, still chair
Because we're in the middle of a chair change, we're having people
contact the chairs by sending email to Hannes and me. (1) This leaves
Derek out. (2) If you do this after the Paris meeting, you'll be
sending email to someone who's not an OAuth chair any more.
You can fix this by *always* using
> OK, I now recognise a culture clash as the underlying point at issue,
> so this spec. is the wrong place to address it.
Ah... so if the issue is how IANA makes registry information
available, then please go to the "happiana" mailing list (
https://www.ietf.org/mailman/listinfo/happiana ) and see
> You have read the spec., and the _only_ concrete thing it tells you
> about the registers is the name of an email list. So you have to go
> to the email archives and search for . . . what exactly? Different in
> the three cases above, and in none of them is it obvious how to know
> what counts
Henry says...
>> No, I appreciate that you want to use registered short names in the protocol,
>> that's just fine. My problem is that you have left users, developers etc.
>> with
>> no way to discover what shortnames have been registered short of a non-
>> trivial and error-prone informal search
Do you have changes to make based on the Apps and TSV Directorate reviews?
Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
> The IESG has received a request from the Web Authorization Protocol WG
> (oauth) to consider the following document:
> - 'The OAuth 2.0 Authorization Protocol'
> as a Proposed Standard
There are some downrefs in this document that need to be called out in
the Last Call notice, which weren't.
> Added to section 1:
>
> TLS Version
>
> Whenever TLS is required by this specification, the appropriate
> version (or versions) of
> TLS will vary over time, based on the widespread deployment and
> known security
> vulnerabilities. At the time of this writing, TLS
> I have asked you to clearly describe the threat, not the mitigation.
>
> It obviously was either not clear or convincing the first time and I am not
> going to start digging through emails when you clearly understand it.
To try to shortcut this:
Mike did lay it out clearly, I think, in his first
Closing out this issue:
> 7.2 Access Token Implementation Considerations
>
> Access token types have to be mutually understood among the
> authorization server, the resource server, and the client -- the
> access token issues the token, the resource server validates it, and
> the client is require
To close out this issue:
There's disagreement about whether this proposed text is "necessary",
but no one thinks it's *bad*, and I see consensus to use it. Eran,
please make the following change in two places in the base document:
> OLD
> The authorization server MUST support TLS 1.0 ([RFC2246]),
> Unless I hear a “no” from Mark, the chairs, or Stephen I’ll plan to publish
> -15 over the weekend. (Or if I hear a “yes”, I’ll do so right away. J)
In general, I always prefer that people have the latest text to review
and comment on, and when there are significant updates to distribute,
a new
> Working group last call begins today on the threat model document:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01
>
> Please review this version and post last call comments by 9 December.
Sorry, folks: I got a little behind here.
Working-group last call is now over. There were
> Working group last call begins today on the threat model document:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01
>
> Please review this version and post last call comments by 9 December.
Here's a reminder that we have about a week left for the working group
last call on this, a
Stephen says:
> On 12/02/2011 03:20 AM, Barry Leiba wrote:
>> Maybe what would work best is some text that suggests what I say
>> above: that toolkits intended for use in implementing OAuth services
>> in general... implement [X and/or Y], and that code written for a
&g
>> So an MTI token type + no client preference is equivalent to there
>> only existing one token type.
>
> Maybe.
>
> However, no MTI token type + no client preference = no interop.
I think this exchange, coupled with what you Stephen said in Taipei
(noting that "mandatory to implement" doesn't me
> The OAuth base doc refers in two places to TLS versions (with the same
> text in both places:
>
> OLD
> The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
> support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
> support additional transport-layer mechanisms meeting its
> And if the servers don't implement the "should" on 1.0 how do we get
> deployments for the other actors that can't talk to 1.2
1. Do you think we'll really see implementations that don't work with
what's out there?
2. SHOULD doesn't mean MAY. SHOULD means "MUST, unless you have a
really good r
> Please refer to this thread about the problem with requiring anything more
> than TLS 1.0
> http://www.ietf.org/mail-archive/web/oauth/current/msg07234.html
>
> You will end up with a spec that virtually no one can implement and be in
> conformance with. I still have yet to find an implementation
The OAuth base doc refers in two places to TLS versions (with the same
text in both places:
OLD
The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
support additional transport-layer mechanisms meeting its security
requ
Stephen, as AD, brought up the question of mandatory-to-implement
token types, in the IETF 82 meeting. There was some extended
discussion on the point:
- Stephen is firm in his belief that it's necessary for
interoperability. He notes that mandatory to *implement* is not the
same as mandatory to
Working group last call begins today on the threat model document:
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01
Please review this version and post last call comments by 9 December.
Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
The chairs have posted minutes to the meeting materials page. Find them here:
http://www.ietf.org/proceedings/82/minutes/oauth.txt
A few messages will follow soon, with action items from the meeting.
Barry, as chair
___
OAuth mailing list
OAuth@ietf.or
> do we have the band width to work on all these items, as some are
> big and some are fairly small and contained. May have to have some
> prioritized list of where people think these fit.
Yes, exactly. And one of the things we'd like to hear from all of you
is what your priorities are... how you
>> Existing practice is that simple ASCII strings like "email" "profile",
>> "openid", etc. are used as scope elements. Requiring them to be URIs
>> would break most existing practice.
>
> Constraining syntax to an ascii token OR a URI (relative reference) might
> work. Anything with a colon can
I'd like to see more participation in this thread, besides just from
Mike and James. What do others think?
Barry, as chair
On Mon, Sep 26, 2011 at 3:05 PM, Mike Jones wrote:
> While you take the viewpoint that the bearer spec is restricting scope
> values, in fact, the spec intentionally allows
> My proposed resolution is that %-encoding not be required in the
> specification
I agree with your analysis, now that I see it laid out clearly. I
would feel better, though, if there were text in the document that
explained that to others, who read it later. Perhaps, using your
words, we could
Stephen,
The OAuth working group requests publication of draft-ietf-oauth-v2-22
as Proposed Standard.
The PROTO writeup is in the tracker:
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/
Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf
As you've all probably seen, Eran has posted version 21 of the OAuth
base spec, in which he believes he's addressed all comments and issues
that came up in the review of version 20. We should be ready to send
this to the IESG.
Everyone who had comments or issues, please review -21 and make sure
t
Following up on this:
On Sun, Jul 31, 2011 at 10:45, Barry Leiba wrote:
> On 7/29/11 3:07 PM, Brian Campbell wrote:
>> Following up from
>> http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html a few
>> weeks ago, I've submitted a new I-D to establish an IET
> I believe we have full consensus on this approach.
I agree, and I will close the issue.
Barry, happy chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On Mon, Aug 22, 2011 at 1:53 PM, Barry Leiba wrote:
> I intend to add the following to the response to this item:
> "The working group understands that client code needs to know whether
> to use and decode percent-encoding. The issue is being discussed and
> tracked, and will b
> +1 for Jame's feedback here. We need to solve this.
I have opened an issue in the tracker on this:
http://trac.tools.ietf.org/wg/oauth/trac/ticket/26
I intend to add the following to the response to this item:
"The working group understands that client code needs to know whether
to use and dec
> Chairs - please open an issue for this: "Clarifying reference to refresh
> tokens
> in section 1.4.3 of -20".
http://trac.tools.ietf.org/wg/oauth/trac/ticket/25
b
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
The text for the answer below came from Mike, as the chairs asked for
at the IETF 81 meeting. Mike, do you have a response to James's
issue? Can we give a better response here? Should the bearer doc
specify %-encoding explicitly?
Barry
On Thu, Aug 18, 2011 at 7:15 AM, Manger, James H
wrote:
>
>> Yes, the example I provided is a very lightweight one which does take the
>> form of CSRF, but it is only the simplest example of a family of automated
>> authorization flow attacks. Indeed, a nonce (or hidden token, both serve the
>> same purpose in this case) would be enough here.
>
> Great. S
> I'd like to ask the chairs to open an issue for this.
http://trac.tools.ietf.org/wg/oauth/trac/ticket/24
> I didn't realize how hyper sensitive this working group has become that every
> proposal being questioned needs a ticket to prove to people that they are not
> being dismissed.
It's OK: t
I'm sorry for the delay in getting this written. Because of the
delay, the working group has just a short time to review my proposed
response, below. Everyone, please have a look at the answers I
propose to send, and post any objections to this thread by the end of
the day on Monday, 22 August.
1 - 100 of 146 matches
Mail list logo
