Given the overwhelming support for this proposal, I am officially asking the
chairs to make a consensus call to break the current document into two parts.
This will be done with the understanding that the result will be reviewed by
the working group again once the parts are stable to determine i
The situation you site is exactly analogous to the situation where sites need
to determine what claims they need to exchange in order to be able to work
together.
There is no provision in the protocol for signaling what claims you understand
and require. It's not that this isn't essential or t
On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland wrote:
> No matter what algorithm or key size we pick the choice will prove
> unsupportable for any number of implementers due to everything from security
> issues (no matter what key size we pick, someone will have a real need for
> something larger)
Quick note:
On Tue, Sep 28, 2010 at 10:23 AM, Dirk Balfanz wrote:
> On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones
> wrote:
>
>> Dirk and I both posted JSON Token drafts on Thursday. They are at
>> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html(which
>> I’ll refer to a
Relying on HTTPS -
I would be interested in use cases where HTTPS isn't available
but OAuth 1.0 signatures are a sufficient substitute. Also, HTTPS should be
used with an application endpoint if it is dealing with high value content.
Bearer tokens and discovery -
In the core OAuth spec the scenario is a tightly related token and application
endpoint. It presumes that they will take the appropriate security mechanisms
between them such as signed tokens but doesn't require any particular solution
for how to implement such a mechanism.
When the issue was e
No matter what algorithm or key size we pick the choice will prove
unsupportable for any number of implementers due to everything from security
issues (no matter what key size we pick, someone will have a real need for
something larger) to legal issues (various countries have their own opinions
Yes Torsten, I believe the consensus we ended up out of that last
discussion was that the spec and associated security considerations
should be written in such a way as to allow for either approach.
On Fri, Oct 1, 2010 at 10:55 AM, Torsten Lodderstedt
wrote:
> Prateek,
>
> as I remember previous
Prateek,
as I remember previous discussions, both design options (self-contained
short-living/one-time use tokens as well as random strings) shall be
feasible. So your contribution would helpful anyway.
regards,
Torsten.
Am 01.10.2010 18:36, schrieb PRATEEK MISHRA:
Torsten,
Brain Campbell
Torsten,
Brain Campbell points out that previous discussions suggest that the
authorization code is meant to be a cryptographically protected one-use
token (vs. a random string) but that these
key (essential!) details are not available draft 10.
http://www.ietf.org/mail-archive/web/oauth/curr
+1, I think this sounds like a sensible path forward
On Tue, Sep 28, 2010 at 8:25 AM, Eran Hammer-Lahav wrote:
> (Please take a break from the other threads and read this with an open
> mind. I have tried to make this both informative and balanced.)
>
>
>
> --- IETF Process
>
>
>
> For those unfa
Glad to see this being worked on here. I wanted to add a few requirements (and
maybe, just maybe, a bit of a solution) into the mix.
As you may recall, in the UMA group we've been working on what we called a
"Claims 2.0" spec (all UMA specs -- and some OAuth-related specs too -- are
linked off
12 matches
Mail list logo
