Glad to see this thread. :)
On Thu, Feb 18, 2010 at 9:14 AM, Eran Hammer-Lahav wrote:
> A few questions we should answer before moving forward. Considering *your*
> use cases and reasons for being here:
>
> 1. Why are you here? What are you trying to solve that is not already
> addressed by exist
On Thu, Feb 18, 2010 at 9:56 PM, Eran Hammer-Lahav wrote:
> But isn't the bearer token itself a sort of plain text secret?
Yes, it is.
The WRAP access token is short-lived, which mitigates some of the
risks. Also note that servers do not need to store access tokens at
all.
The WRAP refresh tok
On Feb 18, 2010, at 9:14 AM, Eran Hammer-Lahav wrote:
> A few questions we should answer before moving forward. Considering *your*
> use cases and reasons for being here:
>
> 1. Why are you here? What are you trying to solve that is not already
> addressed by existing specifications (OAuth 1.0
On Thu, Feb 18, 2010 at 9:14 AM, Eran Hammer-Lahav wrote:
> A few questions we should answer before moving forward. Considering *your*
> use cases and reasons for being here:
>
> 1. Why are you here? What are you trying to solve that is not already
> addressed by existing specifications (OAuth 1
I understand the removal of the client credentials for accessing resources.
That's one less set of credentials accessible by all servers which we already
have consensus. And by not having signatures, there are no secrets to verify.
But isn't the bearer token itself a sort of plain text secret?
On Thu, Feb 18, 2010 at 8:02 PM, Eran Hammer-Lahav wrote:
> Can you apply this (without too much detail) to both WRAP and OAuth 1.0a? I
> think it
> would be useful to see how each comply with these goals (which look pretty
> important to me).
In OAuth 1.0a, every system that needs to create or
Can you apply this (without too much detail) to both WRAP and OAuth 1.0a? I
think it would be useful to see how each comply with these goals (which look
pretty important to me).
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian
> 1. Why are you here? What are you trying to solve that is not already
> addressed by existing specifications (OAuth 1.0a, WRAP, etc)?
I would like to see OAuth 1.0 extended to support more methods for obtaining
tokens to optimize usability for non-web-based clients. I also want to clean
the ov
I have a scenario in which a service provider is offering an API for incoming
messages. It is not possible for this service to require pre-registration of
clients because of the number of possible clients, or the type of clients. In
this scenario, the server is most likely a small site, while th
Peter,
I think, you have captured the meeting's discussion well.
I tried to document the meeting's agreements. Below is my summary of the main
points on which, in my opinion, the participants have agreed (or, at least,
were close to an agreement).
* OAuth should develop specifications that pro
On March 4 2010, the OAuth WG will hold its fourth interim conference
call leading up to IETF 77. Scheduling details and logistics to follow.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
___
FYI for those who missed today's meeting or need to write the minutes.
Original Message
Subject:Fwd: Your recording "OAuth WG Virtual Meeting-20100218 1858-1"
is available for viewing
Date: Thu, 18 Feb 2010 12:32:08 -0800
From: Alexa Morris
To: Pe
On the call people wanted me to clarify what I meant when I talked
about operational security. In a nutshell, I mean:
- what systems and what people have access to long-lived secrets?
Keep this to a reasonable level, where reasonable is defined by
different use cases.
- what systems and what
That was a helpful discussion just now -- thanks to everyone who
participated. Jeff Hodges and I made some *rough* notes via EtherPad at
http://etherpad.com/n2jOXo3WTY and I paste them below. Real minutes will
follow once we've had a chance to listen to the recording.
--Peter
##
OAuth interim #3
Hi,
A few questions we should answer before moving forward. Considering *your* use
cases and reasons for being here:
1. Why are you here?
I'm interested to learn about status and directions of upcomming OAuth
2.0 standard and to contribute my experiences with token based web
service security
FYI. Thanks to Eran for his work on this.
Now let's make progress on OAuth 2.0. :)
Original Message
Subject: Document Action: 'The OAuth 1.0 Protocol' to Informational RFC
Date: Wed, 17 Feb 2010 15:01:36 -0800 (PST)
From: The IESG
To: IETF-Announce
CC: Internet Architecture Bo
On Thu, 2010-02-18 at 10:14 -0700, Eran Hammer-Lahav wrote:
> A few questions we should answer before moving forward. Considering
> *your* use cases and reasons for being here:
>
> 1. Why are you here?
I have built and plan to continue building OAuth implementations. I am
also working on the UMA
A few questions we should answer before moving forward. Considering *your* use
cases and reasons for being here:
1. Why are you here? What are you trying to solve that is not already addressed
by existing specifications (OAuth 1.0a, WRAP, etc)?
2. Should the WG start by taking WRAP or OAuth 1.0
I was not aware that anyone had to bring WRAP back to the table, as I never
realized that you dismissed this as a starting point. So I thought the process
was to go through the use cases which will help distill out some of the
function/features/requirements and I'm sure that will help use choose
19 matches
Mail list logo
