Thanks Eran, this is helpful. Few thoughts:
> We have no business telling servers what they MUST implement (they might
> consider S-Plain too weak for their needs)
Of all the negatives I listed below about SSL, being insecure was not one of
them. I'm very interested in hearing real world use ca
Hey Peter,
Luke put together a spreadsheet comparing the terminology across five or six
different protocols. Hopefully he'll share it. :)
I have a pretty strong preference of sticking with OAuth 1.0 terminology as
much as possible.
--David
On Thu, Jan 28, 2010 at 7:40 AM, Peter Saint-Andre wrot
On Thu, Jan 28, 2010 at 7:10 PM, Eran Hammer-Lahav wrote:
> (For the sake of simplicity, I am going to refer to the Plain bearer token
> with SSL/TLS as S-Plain)
>
> WRAP appeal is also its limitation and (strictly as written) it sacrifices
> security for client ease. We still don’t know what OAut
(For the sake of simplicity, I am going to refer to the Plain bearer token with
SSL/TLS as S-Plain)
WRAP appeal is also its limitation and (strictly as written) it sacrifices
security for client ease. We still don't know what OAuth 2.0 is (it is *not*
WRAP, but likely to include ideas from it).
Thanks for the detailed reply, Eran.
I think that your proposed design has it backwards: servers should bear
complexity and one-time costs, not clients. Much of why I think OAuth WRAP /
2.0 is so appealing is that it dramatically simplifies life for developers. If
a client can support SSL and d
Possibly, although I haven't yet come to the conclusion that these are
incompatible.
Moves to build proper JSON JavaScript libraries rather than rely on the
built-in parser are already tackling some other JSON-related issues, and
could possibly serve to address this issue as well.
Paul
On Thu, 2
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Paul C. Bryan
> Sent: Thursday, January 28, 2010 3:12 PM
> 3. In-browser capabilities (e.g. JavaScript) for manipulating JSON-structured
> data.
>
> That said, there would probably need to
+1 to JSON. Rationale:
1. Allows for structured data with relatively low overhead (unlike flat
name-value pairs).
2. Marshalls/unmarshalls nearly unambiguously to/from native data
structures (dictionaries, arrays, integers, strings, etc.) in multiple
programming languages (unlike XML).
3. In-brows
You're correct. I was thinking too much about reading, not about creating.
This is all about creation. In that case, the absolute simpler the better.
In any case there'll have to be some key-value and pair delimiter which
will need to be escaped within keys and values. The newline idea (where
That definitely seems like a viable option.
Thanks,
George
On 1/27/10 11:44 PM, Paul C. Bryan wrote:
I'm in the #1 camp too. Is it wrong for me to think that discovering
what type(s) of token are acceptable and how to obtain them should be
the domain of XRD?
Paul
On Wed, 2010-01-27 at 20:11 -
Thanks Luke. This is a useful analysis.
I believe we have already reached consensus in this regard:
* Support an extensible set of signature algorithms
* Define hmac-sha-1, hmac-sha-256, and rsassa-pkcs1-v1.5-sha-256
* Define a plain method for bearer tokens and either require SSL/TLS or
strongl
> -Original Message-
> From: Richard L. Barnes [mailto:rbar...@bbn.com]
> Sent: Thursday, January 28, 2010 6:56 AM
> So you're assuming that somewhere in the process of token issuance, the
> client gets told what algorithm to use and remembers it.
Yep.
> When is this assumption true?
We could always just use ASN.1
On Jan 28, 2010, at 4:00 PM, Eran Hammer-Lahav wrote:
That's exactly it.
This is why JSON is not my top priority because people will see 'use
JSON' and ignore the profile (no whitespace) and will fail.
Those of you who picked JSON, does this change your mind
That's exactly it.
This is why JSON is not my top priority because people will see 'use JSON' and
ignore the profile (no whitespace) and will fail.
Those of you who picked JSON, does this change your mind? If we use JSON, I
expect many existing libraries that produce JSON objects to fail becaus
Ah, ok, I misunderstood the context of your reference to XMPP. So the
question at hand here is: How do you construct the thing you're going
to sign?
Assuming that's the question, then the critical thing is that the
format be canonical (or at least canonicalizable). That always seems
eas
This defeats the point of having a unified message format across
different transports. And since the message itself is not sent on the
wire, the benefit to XMPP isn't that significant.
Also, we are only talking about construction, not parsing. So
technically, no lib is really needed in eithe
Speaking not as a core OAuth contributor but as someone who has implemented and
used a few flavors of OAuth, I am +1 on either JSON or form encoded.
John
On Jan 28, 2010, at 7:21 AM, "Luke Shepard"
mailto:lshep...@facebook.com>> wrote:
+1 to JSON. Custom parser is difficult and JSON adds very
One of the topics discussed during our conference call last week was the
matter of terminology. All agreed that we need to gain clarity and
consensus regarding the terms we use. To help us achieve that, I've
created a stub wiki page:
http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthTerms
If you
It's not clear that XML is always crazy. If you're integrating this
into an XMPP client, it's already used to using XML (i.e., it's
already got a parser/generator), and might not have JSON machinery.
I would suggest pinning down a data model that gets serialized to
different formats depend
In the discussions around the OAuth WRAP spec, one of the questions often asked
is, "why use SSL exclusively?" Several of us have done a lot of thinking on it
and I wanted to articulate my understanding of the pros and cons of the
approach for discussion. The use case I primarily have in mind is
+1 to JSON. Custom parser is difficult and JSON adds very little overhead to
the data.
On 1/28/10 7:15 AM, "Justin Hart" wrote:
I'm inclined to say #1 to JSON because its rules are well defined (especially
escaping and delimiters) and the parsers are widely available and relatively
standard.
I'm inclined to say #1 to JSON because its rules are well defined
(especially escaping and delimiters) and the parsers are widely available
and relatively standard. It really has little more complication than other
key-value forms. I say #2 to form-encoded because though there have been
issues, ag
So you're assuming that somewhere in the process of token issuance,
the client gets told what algorithm to use and remembers it.
When is this assumption true? I don't see where it happens in the
OAuth delegation procedure (there's no "use this algorithm" field in
responses that issue token
Eran Hammer-Lahav wrote:
Question: Is the ability for a single token-protected resource to support more
than one token type (say Plain+SSL *and* HMAC-256) part of our requirements? If
not, there is no reason at all for the challenge to include anything other than
#1 or #2 (probably defined as
24 matches
Mail list logo
