http://tools.ietf.org/html/draft-hardt-oauth is the same text document but with
HTML navigation. It will give you links for each section.
EHL
On 1/15/10 8:07 PM, "record...@gmail.com" wrote:
Hey Peter,
Awesome! Thanks Dick!
How can we have an HTML version of it (i.e.
http://www.ietf.org/id/
Hey John,
I think that the OAuth work under way will support your scenarios
other than #3. Signing in with an arbitrary account is currently best
solved via OpenID. OAuth powers Twitter's SSO but requires that each
implementor know specifically that it will be a Twitter user logging
in whereas Op
Hey Peter,
Awesome! Thanks Dick!
How can we have an HTML version of it (i.e.
http://www.ietf.org/id/draft-hardt-oauth-01.html) published as well?
It's much easier to discuss when we can link to specific sections.
Thanks,
--David
On Fri, Jan 15, 2010 at 2:42 PM, Peter Saint-Andre wrote:
> FYI.
Yes, those two drafts make sense. From other threads it sounds like
we're making progress on the Authentication draft which will both
support signatures (ala OAuth 1.x) and plaintext plus SSL/TLS (ala
WRAP). I'll try to start working toward consensus on the core flows
we'd like to support in the
Hello OAuth lists!
Let my briefly introduce myself. I'm John Hurliman, a software engineer on
Intel's Virtual World Infrastructure team. Our team focuses on everything in
immersive connected experiences from performance and scalability to federated
identity and interoperability. My project over
John Kemp wrote:
On Jan 15, 2010, at 5:57 PM, Igor Faynberg wrote:
Right, you were authenticated as an authorized bearer of the token, by matching information about the bearer in the token against additional information you provided separately. That's possible without channel security, of co
OAuth WG Interim Meeting Agenda
Date: 2010-01-21
Time: 19:00 UTC (check for your local time)
Length: 60 minutes
Chairs: Blaine Cook and Peter Saint-Andre
LOGISTICS
Web:
https://workgreen.webex.com/workgreen/j.php?ED=131214267&UID=0&PW=NMTU2ODQyMWY5&RT=MiMyMQ%3D%3D
Password: oauth
Phone (USA/Ca
On Jan 15, 2010, at 5:57 PM, Igor Faynberg wrote:
> Interestingly enough, when I bought, over the Internet, a ticket to Film
> Forum in New York, the way it worked, it amounted to a number (token), which
> I had to redeem at the movie theater. I was authenticated by showing my
> credit card wit
Interestingly enough, when I bought, over the Internet, a ticket to Film
Forum in New York, the way it worked, it amounted to a number (token),
which I had to redeem at the movie theater. I was authenticated by
showing my credit card with which I bought the ticket; I guess I could
have been ask
On Fri, 2010-01-15 at 14:41 -0700, Eran Hammer-Lahav wrote:
>
>
> On 1/15/10 7:58 AM, "John Kemp" wrote:
>
> > When I look at what is possible in the offline world, I would ask - would
> > you
> > require that movie theatre tickets bought in advance were encrypted in
> > transport between the
FYI. Thanks to Dick for submitting this!
/psa
Original Message
Subject: I-D Action:draft-hardt-oauth-01.txt
Date: Fri, 15 Jan 2010 14:15:02 -0800 (PST)
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
A New Internet-Draft is available
On 1/15/10 2:02 PM, "John Kemp" wrote:
> Why would someone bother to sit and capture bearer tokens - what is the value
> of doing that, and what is the actual risk? In some cases, probably not that
> great...
It would be great if the WRAP authors can share with us how their employers
plan to
Hello Eran,
On Jan 15, 2010, at 4:41 PM, Eran Hammer-Lahav wrote:
>
> On 1/15/10 7:58 AM, "John Kemp" wrote:
>
>> When I look at what is possible in the offline world, I would ask - would you
>> require that movie theatre tickets bought in advance were encrypted in
>> transport between the per
On 1/15/10 10:29 AM, "John Panzer" wrote:
> I think the question at hand is: If a server says it wants to do bearer
> tokens and no TLS, is a client obligated to interop in order to claim spec
> compliance?
Its a tricky question because HTTPS is not a parameter or extension you
negotiate. It
On 1/15/10 7:58 AM, "John Kemp" wrote:
> When I look at what is possible in the offline world, I would ask - would you
> require that movie theatre tickets bought in advance were encrypted in
> transport between the person who bought the ticket and the receptionist at the
> cinema? What if the
On 1/13/10 11:12 PM, Eran Hammer-Lahav wrote:
>
> On 1/13/10 6:17 PM, "Peter Saint-Andre" wrote:
>
>>> These drafts will be locked before the WG meeting to allow review and will
>>> be discussed at the meeting. We will also discuss any charter changes
>>> required to accommodate the drafts. This
If the issue is that the client doesn't *want* to do PLAINTEXT-NOTLS,
then there is no interop issue -- the client and the server have
different requirements, at a policy level. You can have a requirement
for compliant implementations to implement the mode, but you can't
force people to use
On Fri, Jan 15, 2010 at 10:41 AM, Richard L. Barnes wrote:
> I would think not; it's a matter of the client's policy what signatures it
> will issue, and the server's policy which it will accept.
>
That doesn't answer the interop question, though, which is the interesting
one from the standpoint
I would think not; it's a matter of the client's policy what
signatures it will issue, and the server's policy which it will accept.
And in any case, OAuth doesn't have any in-band security negotiation,
so there's no way for the server to ask for a given set of features
(e.g., bearer tokens
I think the question at hand is: If a server says it wants to do bearer
tokens and no TLS, is a client obligated to interop in order to claim spec
compliance?
--
John Panzer / Google
jpan...@google.com / abstractioneer.org / @jpanzer
On Fri, Jan 15, 2010 at 10:01 AM, Hurliman, John wrote:
> +
+1 to this as well. Any implementation is free to deviate from the spec, at the
risk of breaking interoperability.
John
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John
Panzer
Sent: Friday, January 15, 2010 8:43 AM
To: Eve Maler
Cc: OAuth
+1 to MUST implement TLS on both sides.
I thought we were only discussing whether the server could decide to
skip TLS for a particular use case. No?
On Friday, January 15, 2010, Eve Maler wrote:
> The points about matching security to use case are excellent. This is why I
> think we're maybe
The points about matching security to use case are excellent. This is why I
think we're maybe misinterpreting Eran's argument for MUST. It's not an
argument from security alone ("we must always have highest security all the
time"); it's an argument from interoperability of security features at
On Jan 14, 2010, at 7:39 PM, Richard L. Barnes wrote:
>> As such, I can't see how *not* requiring SSL for unsigned requests
>> could pass muster at an IETF security review.
>
> Speaking as someone who does IETF security reviews ... :)
>
> If I were reviewing a document that defines an optional
Hi Eran!
On Jan 14, 2010, at 11:41 PM, Eran Hammer-Lahav wrote:
> (this is not aimed at John Kemp)
I think you mean it's not _specifically_ aimed at me, but in any case, I'll
take the opportunity to reply anyway ;)
>
> I understand that some providers will not want to bother with the extra
>
25 matches
Mail list logo
