On 04/23/2012 09:55 AM, Derek Atkins wrote:
Michael Thomas writes:
Derek Atkins wrote:
Michael Thomas writes:
Why not MUST ASN.1 while you're at it? JSON has won in case
you'all haven't noticed it.
Well, now that you mention it... ;-)
But seriously, we're basing this work on an RFC tha
On 04/24/2012 11:10 AM, Peter Saint-Andre wrote:
Indeed you are right, I'd forgotten about that.
The original conclusion was to let oauth progress and move
the discussion to -threats. I brought it up with -threats and
again in last call and got no closure that I recall. Barry's
shepherd review
Indeed you are right, I'd forgotten about that.
On 4/24/12 12:05 PM, Eran Hammer wrote:
> Barry did make a consensus call when this was originally raised.
>
> EH
>
>> -Original Message-
>> From: Peter Saint-Andre [mailto:stpe...@stpeter.im]
>> Sent: Tuesday, April 24, 2012 9:53 AM
>> To:
Berry did make a consensus call when this was originally raised.
EH
> -Original Message-
> From: Peter Saint-Andre [mailto:stpe...@stpeter.im]
> Sent: Tuesday, April 24, 2012 9:53 AM
> To: Eran Hammer
> Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Shepherd rev
There is a lot of history on this thread.
At the heart of it is a request from a working group member that the
specification makes it clear that OAuth does not protect against malware and
viruses, or other malicious software installed on the user device. During the
first (or second, I can't rec
On 04/24/2012 10:26 AM, Phil Hunt wrote:
Michael feels the premise for the document is "borked" because his comments are
not included. However, there are those of us that feel the document instead needs to be
sharply edited back to focus even tighter on OAuth specific issues.
Actually, my la
Folks this is a "scoping" debate. Because this document is a brand new type of
specification, I can see why there is some confusion.
First, I want to point out the concerns Michael Thomas are making are *valid*.
**However** Editorially I feel strongly the comments fall outside the intended
sc
Eran Hammer writes:
> We've been kicking this can of silliness for months now because one
> person refuses to move on even in the face of otherwise unanimous
> consensus from the group.
>
> Chairs - Please take this ridiculous and never ending thread off list
> and resolve it once and for all.
S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/24/12 10:20 AM, Eran Hammer wrote:
> We've been kicking this can of silliness for months now because
> one person refuses to move on even in the face of otherwise
> unanimous consensus from the group.
Hi Eran,
Cans of silliness aside, I'd like t
I think you make JSON's point for it. It has a single, unambiguous,
bidirectional mapping to native data structures in all dynamic languages;
indeed that is its design goal.
XML does not map well to language structures, except in languages designed
explicitly to manipulate it. The duality of eleme
I am sorry that you feel the need to resort to an ad hominem attack,
but my last call comment were not addressed in last call, and this
is the process Barry came up with dealing with them.
And it was hardly "unanimous" and you have no say in determining
consensus so stop presuming to do so.
Mike
We've been kicking this can of silliness for months now because one person
refuses to move on even in the face of otherwise unanimous consensus from the
group.
Chairs - Please take this ridiculous and never ending thread off list and
resolve it once and for all.
EH
> -Original Message
On 04/24/2012 07:10 AM, Mark Mcgloin wrote:
Michael Thomas wrote on 24/04/2012 14:24:47:
The more I read this draft, the more borked I think its base assumptions
are. The client *is* one of the main threats. Full stop. A threat
document
should not be asking the adversary to play nice. Yet, 4.
Are we at this stage re-opening the entire document? I thought we were
responding only to specific shepherd text edits.
Phil
On 2012-04-24, at 6:24, Michael Thomas wrote:
> On 04/24/2012 01:17 AM, Mark Mcgloin wrote:
>> Hi Thomas
>>
>> Your additional text is already covered in a countermeas
Michael Thomas wrote on 24/04/2012 14:24:47:
>
> Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
>
> On 04/24/2012 01:17 AM, Mark Mcgloin wrote:
> > Hi Thomas
> >
> > Your additional text is already covered in a countermeasure for section
> > 4.1.4. In addition, section 4.1.4.
On 04/24/2012 01:17 AM, Mark Mcgloin wrote:
Hi Thomas
Your additional text is already covered in a countermeasure for section
4.1.4. In addition, section 4.1.4.4 states the assumption that the auth
server can't protect against a user installing a malicious client
The more I read this draft,
Hi Thomas
Your additional text is already covered in a countermeasure for section
4.1.4. In addition, section 4.1.4.4 states the assumption that the auth
server can't protect against a user installing a malicious client
Regards
Mark
oauth-boun...@ietf.org wrote on 23/04/2012 17:09:11:
> From:
17 matches
Mail list logo