Hiya,
This draft has a couple of minor changes needed as a result
of IESG review (see [1]) but one question came up that I
wanted to bring back to the WG to see what you think. Any
good answer should be fine btw, this isn't a case of the
insisting on stuff.
The question is whether the WG think t
See below. I think (not quite sure) that this is better
discussed on the kitten list.
Ta,
S.
Original Message
Subject: [kitten] [IANA #731918] SASL mechanism not listed
Date: Mon, 24 Mar 2014 19:33:06 +
From: Stephen Farrell
To: kit...@ietf.org
CC: iana-questi
Mike,
I cannot tell which is your text and which not.
Can you please use a better quoting style? These docs are
going to be a total PITA to handle otherwise.
Thanks,
S.
On 02/10/14 16:14, Mike Jones wrote:
> Responding to the DISCUSS below…
>
>
>
> -Original Message-
> From: Alissa
On 02/10/14 17:25, Mike Jones wrote:
> OK - I'll start prefixing my text with "Mike> ".
Many thanks.
S
>
> -Original Message-----
> From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
> Sent: Thursday, October 02, 2014 8:49 AM
> To: Mike Jones;
Hi Mike,
On 06/10/14 08:54, Mike Jones wrote:
> Thanks for your review, Stephen. I've added the working group to the
> thread so they're aware of your comments.
>
>> -Original Message----- From: Stephen Farrell
>> [mailto:stephen.farr...@cs.tcd.ie] Sent: Thu
Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-saml2-bearer-21: 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
Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-assertions-17: 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
Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-jwt-bearer-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
needed.
>
> On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell
> wrote:
>
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-oauth-jwt-bearer-10: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
&g
Hiya,
Mostly fine just a couple of notes.
On 16/10/14 20:28, Brian Campbell wrote:
> Thanks for your review and feedback, Stephen. Replies are inline below...
>
> On Thu, Oct 16, 2014 at 5:20 AM, Stephen Farrell
> wrote:
>
>> Stephen Farrell has entered the followin
Hiya,
On 16/10/14 21:06, Brian Campbell wrote:
> Thanks for your review and feedback on this one too, Stephen. Replies are
> inline below...
>
> On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell
> wrote:
>
>> Stephen Farrell has entered the following ballot position
On 16/10/14 22:39, Brian Campbell wrote:
> Hiya in return and inline below...
>
> On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell
> wrote:
>
>>
>> Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the
>> JOSE one has only H256 as required.
&g
ietf.org] On Behalf Of Mike Jones
>> Sent: Monday, October 06, 2014 7:20 PM
>> To: Stephen Farrell; The IESG
>> Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-
>> to...@tools.ietf.org; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-assertions-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
-- Mike
>
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
> Sent: Friday, October 24, 2014 8:33 PM
> To: 'Stephen Farrell'; The IESG
> Cc: oauth-cha...@tools.ietf.org;
> draft-ietf-oauth-json-web-to...@tools.ie
gt;>>>
>>>> John B.
>>>>> On Dec 5, 2014, at 10:48 PM, Phil Hunt
>wrote:
>>>>>
>>>>> Doesn't that duplicate our current work?
>>>>>
>>>>> Phil
>>>>>
>>>>>> On Dec
endentid.com
> phil.h...@oracle.com
>
>> On Dec 5, 2014, at 8:43 AM, Stephen Farrell
>> wrote:
>>
>>
>> Hiya,
>>
>> Following up on the presentation at IETF-91 on this topic, [1]
>> we've created a new list [2] for moving that along. The li
+0000
From: Stephen Farrell
To: unbeara...@ietf.org
Hi all,
There's about 70+ people on the list now so let's kick off.
Andrei sent Kathleen and I the charter proposal below a while
ago. For myself I don't think its quite right yet but I'd
rather hear what you all think. S
Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-dyn-reg-28: 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 http
So this is to follow up on my discuss point#2, which said:
(2) If the response (defined in 3.2.1) includes metadata that
the server has altered, but that the client doesn't like, then
what does the client do? (It may be that that's ok, but I'm
not following why that is the case.) I'm also not sur
try to re-negotiate, but
> that's a fairly sophisticated behavior.
So could we just point at the relevant specs for that behaviour?
(Not normatively, and I don't care if they're not RFCs.)
S.
>
> Hope this helps,
> -- Justin
>
> On 4/24/2015 8:09 AM, Stephen Farr
On 24/04/15 13:30, Justin Richer wrote:
>>
>
> OK, so are you asking for something like:
>
> "If the server supports an update mechanism such as [Dyn-Reg-Management]
> and a discovery mechanism such as [OIDC-Discovery], then a smart client
> could use these components to renegotiate undesirable
On 24/04/15 13:28, Justin Richer wrote:
>>
>
> It can get as bad as the web, which is pretty bad, but I hope we don't
> have to point that out in great detail in every RFC that deals with the
> web. :) I think the drive-by-download malware example is a good one, and
> we could add another concre
ake a more
> informed registration request. The use of any such management or
> discovery system is OPTIONAL and outside the scope of this
> specification.
>
> Does this text work for you?
It does, nicely.
Thanks,
S.
>
> — Justin
>
>> On
sufficient to clear the DISCUSS.
>
> Thanks for your thoughtful review!
> — Justin
>
>> On Apr 24, 2015, at 5:32 PM, Stephen Farrell
>> wrote:
>>
>>
>>
>> On 24/04/15 22:27, Justin Richer wrote:
>>> Stephen, I’ve worked on t
Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-proof-of-possession-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
Stephen Farrell has entered the following ballot position for
charter-ietf-oauth-04-00: 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.)
The document, along with
Is there any information as to what percentage of browsers have a
vulnerable configuration? That's not clear to me and seems relevant.
My impression was that wpad wasn't that widely enabled in browsers
nowadays, but that may well be wrong.
S.
On 27/07/16 01:15, Dick Hardt wrote:
> http://arstech
Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-amr-values-05: 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
On 01/02/17 14:58, joel jaeggli wrote:
> On 1/31/17 8:26 AM, Stephen Farrell wrote:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-oauth-amr-values-05: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
fined.
> For all the initial values, that requirement is satisfied, since the
> reference will be to the new RFC. I think that aligns with the point
> that Joel was making.
>
> Your thoughts?
>
> -- Mike
>
> -Original Message- From: OAuth
> [mailto:oauth-boun...@
o match the codepoint. If there's not, I don't see why
adding a codepoint is useful. (Esp. if we're at the stage of
testing "various iris devices" that I would guess do not get
us interop.)
Am I missing something?
Cheers,
S.
>
> -Original Message-
said, I can look at also finding appropriate references for
> the remaining values that don't currently have them. (Anyone got a
> good reference for password or PIN to suggest, for instance?)
>
> -- Mike
>
> -Original Message- From: Anthony Nadalin Sent: Wedne
DISCUSS)
>
> We have interoped between FIDO authenticators vendors and Windows
> Hello
>
> -Original Message- From: Stephen Farrell
> [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017
> 4:24 PM To: Mike Jones ; Anthony Nadalin
> ; joel jaeggli
s that some biometrics fit
that latter but I could be wrong. If they do, then one
runs into the problem of having to depend on magic numbers
in the encodings or similar to distinguish which is really
error prone and likely to lead to what our learned
transport chums are calling ossification;-)
Cheers
Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-jwsreq-12: 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
ions that use some of these
type-names, but the point of RFCs is not to "bless"
such things, but to achieve interop.)
"
Cheers,
S.
>
> Thanks, -- Mike
>
> -----Original Message- From: Mike Jones
> [mailto:michael.jo...@microsoft.com] Sent: Tuesday, February 28, 2017
e useful to RPs. Slicing things more finely than would be used
> in practice actually hurts interop, rather than helping it, because
> it would force all RPs to recognize that several or many different
> values actually mean the same thing to them.
>
>
>
> -- Mike
&g
text. This is such a case - so thanks.
>
> I'll add this information, which is necessary to understand the
> intent, and then republish.
Ah good, that explains the disconnect.
Cheers,
S.
>
> -- Mike
>
> -Original Message- From: Stephen Farrell
> [mailto:ste
Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-amr-values-07: 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
Hi Dave,
On 02/06/11 22:16, Dave CROCKER wrote:
> Stephen,
>
> On 6/1/2011 5:16 AM, Stephen Farrell wrote:
>> Just on DOSETA - that's not currently got any official
>> home in the IETF so its not something that would be right
>> to reference at this point (unless
On 10/06/11 23:17, Eran Hammer-Lahav wrote:
> Extensibility in authentication schemes is a bad thing, given how they are
> deployed and the difficulty of changing them. No existing authentication
> scheme is extensible (explicitly).
Maybe that statement is a tad too general? [1]
S.
[1] http:
On 14/06/11 06:20, Barry Leiba wrote:
> The charter that we discussed here was sent out for internal review on
> 31 May, and was approved by the IESG last Thursday -- that should be
> officially announced any time now. That charter, if you recall, was
> very focused and included milestones for s
FYI, probably best for the WG to see/process these secdir
comments as appropriate. I've not read 'em in detail myself
yet, so as Leif says, feel free to react as appropriate.
S.
PS: Thanks Leif for reviewing this.
Original Message
Subject: secdir review of draft-ietf-oauth-v2
Thanks Barry and all for getting this to this stage. I'll
get you my AD review as soon as I can (though I'll be out
of contact next week). We can then kick off the IETF
LC assuming all's well.
Cheers,
S.
On 09/22/2011 02:48 PM, Barry Leiba wrote:
Stephen,
The OAuth working group requests publi
Hi all,
Now that you've broken the back of the work on oauth 2.0 and
before we get into re-chartering discussions, I think its a
good time to make any chairing changes that are needed.
For a while now, Blaine hasn't really had the required cycles
or e.g. travel support to chair an IETF group an
FYI
S.
Original Message
Subject: [Cfrg] Universally Composable Security Analysis of OAuth v2.0
Date: Tue, 11 Oct 2011 04:36:48 -0700
From: David McGrew
To: c...@irtf.org
Of possible interest: a security analysis of draft-ietf-oauth-v2-20
http://eprint.iacr.org/2011/526
_
Hi all,
Sorry for having been quite slow with this, but I had a bunch
of travel recently.
Anyway, my AD comments on -22 are attached. I think that the
first list has the ones that need some change before we push
this out for IETF LC, there might or might not be something
to change as a result o
Hi Hannes,
Just looking at this now. The tracker [1] WG state shows
revised ID needed - was that prior to the publication request
or as a result of the comments on the list since you sent me
this? If the former, I'll do my AD review now, if the latter
then I guess I should wait and review a -13.
Hi,
Good work - another one almost out the door! Thanks.
However, I think this one needs a revised ID before we start
IETF LC. Nothing hard to change I hope, but I think there
are enough changes to make that its best done that way.
I reckon items 3,5,7-11 and 13 below need fixing, but are
I ho
h it so long as the set of things that
are MTI is clear.
Incidentally, I don't believe any amount of +1 messages to your
mail answer my point above. As Eran's mail asks: what is it
that you're suggesting be MTI for whom?
S.
regards,
Torsten.
Am 13.10.2011 19:13, schrieb Stephen
Agnostic sounds like a fine word.
I'd need to have it demonstrated to me that it doesn't
mean non-interoperable in this case.
S.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
So perhaps this is the interesting point of difference.
On 11/02/2011 08:37 PM, John Bradley wrote:
It is up to the server to decide what formats it will support.
With IETF protocols, its IETF consensus that decides this in
almost all cases that affect interop and it is therefore not
up to th
On 11/05/2011 07:36 PM, Hannes Tschofenig wrote:
Hi all,
after a discussion with Stephen we decided that it would be useful to have
draft-ietf-oauth-v2-bearer-14 submitted during the blackout period so that we
have the most recent feedback incorporated already before the IETF meeting
starts
Reminder: please send your wg summary messages to saag before
the session at 1520!
Nea and oauth: I know that's quite demanding
Dane: you met Monday :-)
Thanks,
S.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
oops - meant just for the chairs, apologies.
S
On 11/17/2011 02:44 AM, Stephen Farrell wrote:
Reminder: please send your wg summary messages to saag before
the session at 1520!
Nea and oauth: I know that's quite demanding
Dane: you met Monday :-)
Than
On 12/01/2011 08:10 PM, Peter Saint-Andre wrote:
On 12/1/11 1:09 PM, Rob Richards wrote:
On 11/28/11 10:39 PM, Barry Leiba wrote:
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
Barry, all,
First, apologies for being so slow responding, various
travels got in the way. I hope we can quickly resolve this now.
Bit of process first: at the meeting we discussed this and at the
end of that discussion, there were quite a few more folks for the
"pick one" position. People who
overy stuff in pretty short order I think if we needed
to.
Really? Doesn't the WG first need to recharter? We're talking about
how to get the base spec to be an RFC right now, which is a shorter
term thing IMO.
S.
-bill
________
From: Stephen Farrel
for use with OAuth2 seems to be a good way to go.
We disagree about that I guess. To me it seems a peculiar way to go
unless one assumes that coders write code that's specific to a specific
service provider.
S.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2011-12
Hiya,
On 12/02/2011 01:38 AM, Michael D Adams wrote:
I echo Justin Richer's comments.
On Thu, Nov 17, 2011 at 12:28 AM, Barry Leiba wrote:
1. Should we specify some token type as mandatory to implement? Why
or why not (*briefly*)?
No. There's no mechanism in the spec for clients to reque
too heavy. If the WG do
pick an MTI then it does need to be relatively simple.
S.
________
From: Stephen Farrell
To: Phil Hunt
Cc: Barry Leiba; oauth WG
Sent: Thursday, December 1, 2011 5:23 PM
Subject: Re: [OAUTH-WG] Mandatory-to-implement token type
On 12/02/2011
Hi Mike,
On 12/02/2011 01:35 AM, Michael Thomas wrote:
On 12/01/2011 05:23 PM, Stephen Farrell wrote:
E.g. MAC tokens work well for non-TLS protected resources. Bearer
tokens in contrast are easier to use, but require TLS protected
service to avoid theft-of-credential.
So picking is a
Hiya,
On 12/02/2011 02:14 AM, Michael D Adams wrote:
On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell
wrote:
On 12/02/2011 01:38 AM, Michael D Adams wrote:
So an MTI token type + no client preference is equivalent to there
only existing one token type.
Maybe.
However, no MTI token type
Hi Barry,
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
specific environment implement what makes
FWIW, if Barry's suggested text was amended to say "MUST do bearer,
MAY do mac" I'd still be ok with that.
Much as I'd like if the mac scheme were more popular, my comment
on -22 was interop and not really security related.
S
On 12/04/2011 01:15 PM, Paul Madsen wrote:
Commercial OAuth authori
ld be completely silent on MAC, as it is not ready for prime
time.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Stephen Farrell
Sent: Sunday, December 04, 2011 6:20 AM
To: Paul Madsen
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandato
rds something
self-consistent. Again though, that's also not the current issue
under discussion, and in that case, I guess there is (or was,
seems quiet now) a re-chartering thread that seems appropriate
for that topic.
Cheers,
S.
EHL
-Original Message-
From: oauth-boun...@ietf.o
Hannes,
I don't see any proposed text here, I see re-chartering
suggestions. The latter is not going to happen if the
current main documents are wedged. Please focus on the
former now.
You know that I disagree with you and a number of WG
participants about this, so no need for me to repeat
myse
aint-Andre
Sent: Thursday, December 01, 2011 12:59 PM
To: Stephen Farrell
Cc: Barry Leiba; oauth WG
Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
On 12/1/11 1:57 PM, Stephen Farrell wrote:
On 12/01/2011 08:10 PM, Peter Saint-Andre wrote:
On 12/1/11 1:09 PM, Rob Richards wro
On 12/18/2011 07:00 PM, Barry Leiba wrote:
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 va
ds resolve themselves)
is the way to go.
Thanks,
S.
On 01/20/2012 11:47 PM, Eran Hammer wrote:
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Thursday, October 13, 2011 10:13 AM
List 1 - Fairly sure these ne
Same response as for part I from me,
S
On 01/21/2012 01:04 AM, Eran Hammer wrote:
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Thursday, October 13, 2011 10:13 AM
Suggested non-trivial clarifications
As before,
Thanks
S
On 21 Jan 2012, at 02:53, Eran Hammer wrote:
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Stephen Farrell
>> Sent: Thursday, October 13, 2011 10:13 AM
>
On 01/23/2012 05:11 PM, Mike Jones wrote:
FYI, the OAuth Core and Bearer specifications have reached IETF last call
status - the last step before becoming RFCs. See the following notes from the
Internet Engineering Steering Group (IESG).
Not quite the last step. There may be directorate re
Folks,
The OAuth bearer and base last calls had to be re-done
since I forgot to include some downref information. Other
than adding a day to IETF LC, there should be no other
difference.
Sorry about that.
S
On 01/24/2012 03:00 PM, The IESG wrote:
The IESG has received a request from the Web
vious reference to RFC 2818 was
changed to RFC 6125 in draft 14 at the request of Security Area
Director Stephen Farrell.
I've quickly chatted with Stephen and he said that he only asked the
question and didn't necessarily instructed the WG to do the change from
RFC 2818 to RFC 6125. Keepi
Hi all,
As some of you will have noticed Barry will be taking
over as an IETF applications area director in Paris
which means that he'll no longer be able to help out
as OAuth chair after that.
However, we've been quite lucky in that Derek Atkins
(cc'd) has agreed to help out along with Hannes
Thanks Eran,
A question...
Is this text in 3.1.2.5 correct?
If third-party
scripts are included, the client MUST NOT ensure that its own scripts
(used to extract and remove the credentials from the URI) will
execute first.
"MUST NOT ensure" is a really odd construct. Maybe s/NOT//
First, thanks all, but especially editors and chairs, for your
efforts on these. I'll be putting them on an IESG telechat
agenda very shortly.
That'll be for after the Paris meeting though, but only because
we have a monster 700 pages of I-Ds to go through for next week's
telechat due to outgoin
Hi Mike,
On 03/08/2012 03:31 PM, Mike Jones wrote:
Hi Stephen,
I wanted to verify that, despite this state change, that it's still OK for me
to make the editorial change suggested by the WG to the Bearer spec to change
the b64token example.
Sure. Changes the WG want that don't conflict wit
FYI in case some aren't on i...@ietf.org
Having responses to these before Thursday would be good. Its
often the case that some AD will turn some of these points into
a DISCUSS so good to know what can be cleared up easily and
what might need further discussion before the telechat.
S
O
On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:
> Hi all,
>
> those who had attended the last IETF meeting may have noticed the
ongoing activity in the 'Applications Area Working Group' regarding Web
Finger.
> We had our discussion regarding Simple Web Discovery (SWD) as part of
the re-chart
Hi All,
So Hannes and Derek and I have been discussing this with
the Apps ADs and Apps-area WG chairs. I've also read the
docs now, and after all that we've decided that this topic
(what to do with swd and webfinger) is best handled in the
apps area and not in the oauth WG.
The logic for that is
Hi all,
A recent news article [1] was brought to my attention this week
that's about a paper [2] which I've just read. While it mostly
deals with implementation and integration flaws, I'm wondering
if there's anything in there that could benefit any of the
oauth drafts. Anyone had a look at that
On 04/20/2012 03:40 PM, Michael Thomas wrote:
>
> Why not MUST ASN.1 while you're at it? JSON has won in case
> you'all haven't noticed it.
Well, I also remember when XML won over ASN.1, or
was that some RPC thing? Seems like a new format wins
about every five years or so, once the last winner
us: Active
> Last updated: 2012-05-03
>
> Chairs:
> Hannes Tschofenig
> Derek Atkins
>
> Security Area Directors:
> Stephen Farrell
> Sean Turner
>
> Security Area Advisor:
> Stephen Farrell
>
> Technical Advisor:
> Peter Saint-Andre
>
&
Hi Mike,
On 05/09/2012 08:34 PM, Michael Thomas wrote:
> On 05/09/2012 12:17 PM, Eran Hammer wrote:
>> Whoever you talk to for legal advice about IPR issues related to
>> standards you might implement. My only point is, this group is not
>> qualified to comment on IPR matters.
>
> The IETF gets
On 05/09/2012 09:31 PM, Michael Thomas wrote:
>>
>
> That's not what I read Eran as asking for:
>
> "So no discussion of this is expected on the list - correct?"
Eran is right about the kinds of discussion I mentioned
as not being for the WG.
This is all business as usual, the rules are in RF
not sufficiently familiar with the current state of
play to include "JSON-based" so I've left that out.
> Typo: Change "a authorization" to "an authorization".
Ta,
S.
>
> -- Mike
>
> -Original Message-
&g
Hi all,
I've gotten the publication request for oauth-threatmodel
so here's my AD review of -05.
Its quite a read (and a good one) but I've a bunch of
questions. Some of these will need fixing I suspect
but a lot are ok to fix later after IETF LC, depending
on whether the authors want to re-spi
Torsten.
>
> Am 28.05.2012 20:34, schrieb Stephen Farrell:
>>
>> Hi all,
>>
>> I've gotten the publication request for oauth-threatmodel
>> so here's my AD review of -05.
>>
>> Its quite a read (and a good one) but I've a bunch of
>>
Hi all,
Just so's you know, I've requested the additional IETF LC
on the oauth bearer draft.
This is because a reviewer after the previous IETF LC and
after the IESG telechat noticed some IPR and did the right
thing.
I think we're close enough to done that folks can make
their evaluations of wh
Hi all,
Just to let you know that all discusses on
draft-ietf-oauth-v2 have now cleared. So
that means that when the chairs tell me
you've finished the last few updates needed,
I can shoot this on to the RFC editor (as
long as you don't mess about adding crazy
stuff:-).
Let's get this one out th
On 06/15/2012 07:54 PM, Mike Jones wrote:
> Bearer acknowledges Bill de hÓra. Core acknowledges Bill de hOra. Which is
> correct?
Bill may correct me but I believe the former is correct but
can't be represented in ASCII so the latter is what you ought
use.
S
Hi Mike,
As you noted this is under way. When I mailed tlr I
asked for two weeks from the 13th, which co-incides
with the end of the IETF LC caused by the IPR
declaration, so it should be fine.
Cheers,
S.
On 06/18/2012 07:08 PM, Mike Jones wrote:
> Hi Stephen,
>
> Pete is holding his DISCUSS o
Hi,
Many thanks for a nice short document!
I've a few questions though and suspect that a quick re-spin
might be needed, but let's see what the wg think about 'em
first.
(1) Why Informational? Everything else at that level seems to
be specified in a standards track or BCP level RFC, and IETF
Co
On 06/20/2012 05:14 PM, Mike Jones wrote:
> Per your question (5) Stephen, possibly see the registrations in
> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6.
> Authors, maybe using one of these as an example would help?
Thanks Mike, that answers the question. I can't s
ack. Responses are inline.
>
> On Wed, Jun 20, 2012 at 6:26 AM, Stephen Farrell
> wrote:
>>
>> Hi,
>>
>> Many thanks for a nice short document!
>
> If only they could all be so short right? :)
>
>> I've a few questions though and suspect
On 21 Jun 2012, at 19:29, Barry Leiba wrote:
>>> (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?
>>>
>> Standa
1 - 100 of 136 matches
Mail list logo
