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
in the 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:stephen.farr...@cs
s 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
>
>
>
> -Original Me
se
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
> 6:17 PM To: Stephen Far
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
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,
S.
>
> Best wishes, -- Mike
>
ject: RE:
> [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
>
> We have interoped between FIDO authenticators vendors and Windows
> Hello
>
> -Original Message- From: Stephen Farrell
> [mailto:stephen.farr...@cs.tcd.ie] Sent: W
epoint. 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- From: Stephen Farrell
> [m
fied, 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...@ietf.org] On Behalf Of Stephen Farrell Sent:
> Wednesday, Febr
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
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
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
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
for your thoughtful review!
— Justin
On Apr 24, 2015, at 5:32 PM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
On 24/04/15 22:27, Justin Richer wrote:
Stephen, I’ve worked on this this afternoon and this is my proposed text:
The response to such a
situation is out
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 concrete one
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
, Stephen Farrell wrote:
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
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
, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
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
: Stephen Farrell stephen.farr...@cs.tcd.ie
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. So please
, 05 Dec 2014 16:43:19 +
From: Stephen Farrell stephen.farr...@cs.tcd.ie
Reply-To: Stephen Farrell stephen.farr...@cs.tcd.ie
To: s...@ietf.org s...@ietf.org, websec web...@ietf.org,
u...@ietf.org u...@ietf.org, ietf-http...@w3.org Group
ietf-http...@w3.org, http-a...@ietf.org http
(again).
I think the architectural/protocol issues around the use of load balancers
have to be discussed as the current ALPN proposal may be unbearable for many.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Dec 5, 2014, at 8:43 AM, Stephen Farrell
-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.ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
draft-ietf-oauth-json-web
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 draft-ietf-oauth-json-
web-token-27: (with DISCUSS and COMMENT)
Thanks for tracking all of this Stephen
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
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
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
at 5:22 AM, Stephen Farrell stephen.farr...@cs.tcd.ie
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
email addresses included in the To and CC lines
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 stephen.farr...@cs.tcd.ie
wrote:
Stephen Farrell has entered the following ballot
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 stephen.farr...@cs.tcd.ie
wrote:
Stephen Farrell has entered the following ballot position for
draft
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 stephen.farr...@cs.tcd.ie
wrote:
Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the
JOSE one has only H256 as required.
Doesn't that seem like
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: Thursday, October 02, 2014
5:03 AM
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; Alissa Cooper; The IESG
Cc: oauth-cha
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 stephen.farr...@cs.tcd.ie
To: kit...@ietf.org
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
Hiya,
On 05/13/2013 09:04 AM, Hannes Tschofenig wrote:
Hi all,
the OpenID Connect had gained some experience with using version control
systems
for editing specifications (and the use of issue trackers), see
http://openid.bitbucket.org/. Based on a recent discussion in the IETF (among
Lodderstedt wrote:
Hi Stephen,
I just posted a new revision of the draft
(http://tools.ietf.org/html/draft-ietf-oauth-revocation-07). I tried to
address all the issues you raised (see below).
Am 09.04.2013 19:27, schrieb Stephen Farrell:
Hi,
I've done my AD review of this draft. I have two
Hi,
I'm surprised there've been no responses. I thought
there was more interest in this one.
Ta,
S.
On 04/09/2013 06:27 PM, Stephen Farrell wrote:
Hi,
I've done my AD review of this draft. I have two quick questions
I'd like to get answered before I start IETF LC. Depending
Hiya,
On 04/12/2013 10:03 PM, Justin Richer wrote:
Hi Stephen,
I didn't respond as I didn't have anything to add to your comments, but
what little details I have are inline.
Thanks:-)
On 04/12/2013 04:53 PM, Stephen Farrell wrote:
Hi,
I'm surprised there've been no responses. I
Hi,
I've done my AD review of this draft. I have two quick questions
I'd like to get answered before I start IETF LC. Depending on the
answers maybe we should re-spin or just fire ahead, let's see...
(1) 2.1: upon the return of the request isn't right is it? I
think you mean the response at
been deployed by four companies, namely by Salesforce,
Google, Deutsche Telekom, and MITRE.
The working group reviewed and discussed the document extensively.
Personnel:
Hannes Tschofenig is the document shepherd. The responsible area director is
Stephen Farrell.
(3) Briefly describe
This looks right to me (and I'm in a boring meeting processing
errata:-) so I'm gonna mark it as verified. Please let me know
if that's wrong.
S
On 02/26/2013 05:07 PM, RFC Errata System wrote:
The following errata report has been submitted for RFC6749,
The OAuth 2.0 Authorization Framework.
is interoperability theatre if you are pretending it will make arbitrary
OAuth deployments automatically work together.
Regards
John B.
On 2013-02-19, at 4:22 AM, SM s...@resistor.net wrote:
Hi John,
At 12:54 18-02-2013, John Bradley wrote:
That is where we get into the area Stephen Farrell
Hi Barry,
I agree with you generally, but just on one point...
On 02/18/2013 05:38 AM, Barry Leiba wrote:
That's why I say that as I see it, it's not an issue of MTI.
I do think there is an issue related to MTI that's affecting
the discussion. Clearing up that issue won't by itself solve
Hi all,
The OAuth assertion document has received DISCUSSes as you can
see from the data tracker at [1]. I've been chatting with
the chairs and the ADs with those DISCUSSes in the last few
days.
The main concern is that these documents do not sufficiently
specify the functionality that is
In some off-list mail between Mike and I, he said:
Was TCP a bad idea because it didn't have MTI port numbers? Would
it have improved TCP to add an MTI port or two?
To which I responded:
Ports are MTI for TCP. [1] They are 16 bit values
with a well-defined test for equality and a little
Hi Hannes,
On 01/19/2013 04:19 PM, Hannes Tschofenig wrote:
Thanks for the feedback. I see that a couple of you have decided to go with
option 2.
Yep, looks like it. I've moved this back to Feb 7 so the
discussion doesn't need to be rushed.
S.
Hiya,
So I'll take the lack of further discussion about this an meaning
that the wg want this to shoot ahead. I'll put this in as an RFC
editor note for the draft.
Cheers,
S.
On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
Hi all,
As you have seen on the list (see
Hi,
Since we thought we were done with it, I put this document
on the IESG telechat agenda for Jan 24. Hannes' question
however looks like its a real one that needs an answer.
I'd appreciate it if the WG could figure out if there's any
change needed and either make that change in the next week,
On 01/09/2013 11:02 PM, Derek Atkins wrote:
Barry Leiba barryle...@computer.org writes:
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
-
Hi Hannes, all,
Sorry to have been slow with the AD review here. I've only
a few comments (below) that can be handled as IETF LC
comments. Any changes as a result of the recent thread on
the definition of Issuer can also be done then.
Unless someone tells me to hold off for a new version, I'll
Thanks,
Since this is on the Aug 30 telechat let's not have any further changes
without a chair/AD asking.
Ta,
S
On 16 Aug 2012, at 18:19, Torsten Lodderstedt tors...@lodderstedt.net wrote:
Hi all,
the new revision covers token substitution, which has been added to the core
spec
:
Stephen
One more threat has come up in the core spec that is being looked at. As
Torsten is heading out on vacation I have agreed to augment if needed with
any supplementary text to the threat model.
Will keep you informed.
Phil
On 2012-06-27, at 17:17, Stephen Farrell stephen.farr
Hiya,
On 07/23/2012 08:56 AM, Julian Reschke wrote:
On 2012-07-23 00:33, Stephen Farrell wrote:
Hi all,
I'd like to check that some recent minor changes to this
document [1] don't cause technical or process-grief.
The version [2] of the oauth bearer draft that underwent
IETF LC and IESG
Hi all,
I'd like to check that some recent minor changes to this
document [1] don't cause technical or process-grief.
The version [2] of the oauth bearer draft that underwent
IETF LC and IESG evaluation had a normative dependency
on the httpbis wg's authentication framework. [3]
After
Hi,
This draft was approved on yesterday's IESG telechat.
Before sending it off to the RFC editor would you take
a look at the comments [1] and let me know if there are
any changes worth making.
If they're tiny but worth doing, (which they probably are)
I can put them in as an RFC editor note,
Folks. Please don't develop any new revisions for these
documents right now. I know you can't officially post
'em anyway, but I don't want us to get tempted to roll
new versions handling unrelated comments. (Alexey's
comments are not unrelated.)
I'd like to handle any tweaks needed as RFC editor
Hi Hannes,
That's great thanks. And thanks all for the good work.
Since there've been a good few changes and a bit of time
has elapsed I'll give the other IESG members who previously
commented on these a few days to check if the changes are
ok, and then I can shoot 'em along.
Cheers,
S.
PS: A
comments.
Please find answers to your comments below.
Thank you again for your detailed review. You helped us to significantly
improve the document's quality.
best regards,
Torsten.
Am 28.05.2012 20:34, schrieb Stephen Farrell:
Hi all,
I've gotten the publication request for oauth
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 see
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 on
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
long it will take (due to daytime job load).
Sure. With 3 authors and most of the comments only needing trivial
fixes, I'd hope that's not too long a job. (Or, if it is, maybe
ask the chairs to try find more help.)
Cheers,
S.
best regards,
Torsten.
Am 28.05.2012 20:34, schrieb Stephen
:
Hannes Tschofenig hannes.tschofe...@gmx.net
Derek Atkins de...@ihtfp.com
Security Area Directors:
Stephen Farrell stephen.farr...@cs.tcd.ie
Sean Turner turn...@ieca.com
Security Area Advisor:
Stephen Farrell stephen.farr...@cs.tcd.ie
Technical Advisor:
Peter Saint-Andre stpe
to include JSON-based so I've left that out.
Typo: Change a authorization to an authorization.
Ta,
S.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Stephen Farrell
Sent: Wednesday, May 09, 2012 7
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
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
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
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
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
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
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
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
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
As before,
Thanks
S
On 21 Jan 2012, at 02:53, Eran Hammer e...@hueniverse.com 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
Original list of nits
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
, 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 wrote:
On 11/28/11 10:39 PM
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
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] Mandatory
, 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.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Sunday, December 04, 2011 6:44 AM
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
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
On 12/01/2011 11:37 PM, William Mills wrote:
Re: So, pick one (my strong personal preference) or establish and
document why you're not picking one seem to me to be the choices
available.
We don't have discovery done (enough) yet to lean on it in the core spec, but
if we did I'd be in favor
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-01, at 1:25 PM, Stephen Farrell wrote
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 Leibabarryle...@computer.org wrote:
1. Should we specify some token type as mandatory to implement? Why
or why not (*briefly*)?
No. There's no mechanism in the
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-01, at 1:25 PM, Stephen Farrell wrote
Hiya,
On 12/02/2011 02:14 AM, Michael D Adams wrote:
On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell
stephen.farr...@cs.tcd.ie 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
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 :-)
Thanks,
S
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
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
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 Farrell:
Hi all,
Sorry for having been quite
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
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
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
1 - 100 of 112 matches
Mail list logo
