Mark,
ยง5.1.1 (where the ABNF for credentials is defined) will move out of the OAuth
core spec in the doc split.
I would like to see the bearer spec use a non-OAuth scheme name when it defines
its Authorization header.
I strongly favour restricting tokens to a much smaller alphabet, such as the
--
James Manger
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mark
Lentczner
Sent: Thursday, 28 October 2010 10:44 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth v2 Authorization Header Credentials
In my work implementing OAuth v2 to draft
I'm not sure what you mean by signatures improving privacy? I don't see
signature having much effect on privacy. Encryption is needed for that.
However, signatures do limit the scope of exposure should a token get
exposed in some manner. In that sense a user is protected because a
leaked token
In my work implementing OAuth v2 to draft 10, I have had to review the
definition of credentials included in an Authorization header. I
believe this current definition has some significant issues for
parsers. However, with some small clean up of the definition, proposed
below, I believe that the cr
On Oct 27, 2010, at 8:09 PM, Freeman, Tim wrote:
> The questions currently interesting to me about use cases are:
>
> * The only use cases that made sense to me about signatures used them for
> auditability, where they enabled blame to be properly placed after
> information leaked to the wrong
Hi James,
Finally got around to get an answer for your question:
"GOOG1 is an authentication scheme specific to Google Storage for
Developers, and is designed to provide interoperability with a large
number of cloud storage tools and libraries that work with services
such as Amazon Simple Storage
>* Use cases that justify a feature seem to require two parts -- an example
>>where the feature is absent and therefore a particular problem cannot be
>>solved, and an example where the feature is present and the same problem >can
>then be solved.
There are use cases that can be supported by mo
Another use case for signatures is gross management of relationships,
controlling the secrets in use for (I'll misuse the term) peers allows a single
point of control for that relationship.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of
On the face of it, it seems that discussion of whether and how to split the
document has derailed collection of use cases. If we had consensus on a list
of use cases, that would mean we have identified the problems we're trying to
solve. This would still allow slimy political manipulation of t
These posts of Yaron's outline the basic vision and flows:
http://www.goland.org/adhocauthentication/
http://www.goland.org/oauthgenericdelegation/
We hope to also come out with a description in Internet-draft style soon to
provide concrete details about possible i
So, after a tough fight with Alexey (which I lost) here is another proposal
for the tutorial. There is the IAB technical plenary talk from 16:30 to
19:30. We would meet after the tutorial for the tutorial.
Drop me a note if this alternative proposal does not work for you.
Ciao
Hannes
On 10/27/10
The APPs area people are already aware of Oauth; they are welcome in the
afternoon for the security discussion.
There will always be a conflict and I wanted to have it at the beginning of
the week to leave room left for further sessions during the week, if
necessary.
On 10/27/10 3:13 PM, "Alexey
Hannes Tschofenig wrote:
Hi all,
Based on the positive response at the last IETF meeting we decided to hold
another Oauth tutorial, namely on Monday, November 8,0900-1130
I am sorry Hannes, but having this tutorial during the Apps Area open
meeting is not cool.
So "-1" from one of your Ap
Hi all,
We will start our conversations about Oauth security on Monday, November 8,
1300-1500.
As a starting point I suggest to look at:
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
http://tools.ietf.org/id/draf
Hi all,
Based on the positive response at the last IETF meeting we decided to hold
another Oauth tutorial, namely on Monday, November 8,0900-1130
If you plan to participate drop me a note.
I will post information about the meeting room to the Oauth mailing list in
time before the meeting.
Ciao
Hi all,
based on the feedback from the group on the list we go forward with the
document split.
Mike had kindly offered to edit the bearer specification and we are happy to
hear that. Thank you Mike. I am looking forward to see the first document.
Ciao
Hannes
On 10/14/10 3:32 AM, "Blaine Cook
Kiva is in the process of implementing OAuth for our API. The current 2.0 draft
lacks signatures which we determined as a necessary layer of protection for
some of our transactions. However, 1.0 is unnecessarily complex and offers a
misleading sense of security for apps that can't keep secrets.
17 matches
Mail list logo
