Am 28.07.2010 um 01:40 schrieb Brian Eaton :
> On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
> wrote:
>> There seem to be two potential arguments against it - the burden of
>> tracking the state and the potential that it's unnecessarily
>> restrictive. I don't personally see either as being a
If nobody does, I could since this is one of the most crucial piece that I
need.
=nat @ Tokyo via iPhone
On 2010/07/27, at 17:36, Eran Hammer-Lahav wrote:
> Is someone going to turn this into an I-D anytime soon?
>
>
>
> EHL
>
>
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@i
If nobody does, I could since this is one of the most crucial piece that I
need.
=nat @ Tokyo via iPhone
On 2010/07/27, at 17:36, Eran Hammer-Lahav wrote:
> Is someone going to turn this into an I-D anytime soon?
>
>
>
> EHL
>
>
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@i
Is someone going to turn this into an I-D anytime soon?
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dirk
Balfanz
Sent: Tuesday, July 27, 2010 4:04 PM
To: Nat Sakimura
Cc: oauth
Subject: Re: [OAUTH-WG] OAuth Signature
On Tue, Jul 27, 2010 at 3:35 PM, Nat Sakimu
On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
wrote:
> There seem to be two potential arguments against it - the burden of
> tracking the state and the potential that it's unnecessarily
> restrictive. I don't personally see either as being a major issue but
> would like to hear from folks if t
Hi.
Currently, the discovery document would have something like:
{
"verification_keys": {
"key1":"RSA.ALqcwR...",
"key2":"X509.
}
}
It defines RSA and X509. Could we define a third type "certs_url" that
points to the
file that stores PEM format ce
Thanks for sharing!
One question: Was there a particular reason for having signature first
instead of the payload?
On Tue, Jul 27, 2010 at 7:18 AM, Paul Tarjan wrote:
> Facebook released an early version of the proposed signature method, with the
> aim of getting real-life implementation experi
On Tue, Jul 27, 2010 at 3:35 PM, Nat Sakimura wrote:
> On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz wrote:
> >
> >
> > On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura
> wrote:
> >>
> >> I have a fundamental question.
> >>
> >> While separating signature and payload by a dot "." seems ok,
> >> I
On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz wrote:
>
>
> On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura wrote:
>>
>> I have a fundamental question.
>>
>> While separating signature and payload by a dot "." seems ok,
>> I still have not the answer for the question "why not make everything
>> int
On Wed, Jul 28, 2010 at 5:43 AM, Dick Hardt wrote:
>
>
> On 2010-07-27, at 12:34 AM, Nat Sakimura wrote:
>
>> I have a fundamental question.
>>
>> While separating signature and payload by a dot "." seems ok,
>> I still have not the answer for the question "why not make everything
>> into JSON and
On 2010-07-27, at 12:34 AM, Nat Sakimura wrote:
> I have a fundamental question.
>
> While separating signature and payload by a dot "." seems ok,
> I still have not the answer for the question "why not make everything
> into JSON and base64url it?".
bloat from base64 encoding twice
>
> BTW,
Now that the I-D submission process/tool is open again, I went ahead
and submitted the "SAML 2.0 Bearer Assertion Profile for OAuth 2.0" as
an I-D. It's basically the same as the version I posted to the WG
mailing list except I added some language in the introduction stating
the intended similarit
On Tue, Jul 27, 2010 at 12:26 PM, Chuck Mortimore
wrote:
> For both of these, We intend to enforce one time use; I suspect that type of
> state maintenance will get argued against by those running the large
> scale consumer systems...it's manageable for us given how our Multi-tenancy
> is setup.
On Tue, Jul 27, 2010 at 10:31 AM, Justin Richer wrote:
> The second use case I outlined is not a distributed app and does not fit
> the case for dynamic registration at all. It is a server with a securely
> stored and guarded secret. The same user can have multiple authorized
> inputs (email addre
Yes - this is intended to be a simplified parallel to web sso profile. We also
intend to ship a straight adaptation of websso, as do others I believe
For both of these, We intend to enforce one time use; I suspect that type of
state maintenance will get argued against by those running the large
The second use case I outlined is not a distributed app and does not fit
the case for dynamic registration at all. It is a server with a securely
stored and guarded secret. The same user can have multiple authorized
inputs (email addresses in this case) to this server, and all are stored
with separ
Good question. Probably because the authz servers wants to realize the
relationship in order to apply a client (== partner) specific policy to all
instances or to present the end user with a tree like view in user self care,
like this
My EPG
Epg on iPhone
Epg on Nexus One
regards,
Torsten.
On Thu, Jul 22, 2010 at 3:39 PM, Torsten Lodderstedt
wrote:
> Sounds like you defining a profile of the OAuth assertion flow for using
> SAML assertions complying to the SAML "Web Browser SSO Profile". I think you
> should state that somewhere. There will probably be other assertion flow
> profile
Is there value in pre-registering a binary that gets distributed? How
is this better than this application acting anonymously?
At some point it was suggested that applications that are distributed
could do automatic registration of each instance, at which point they
are also issued a secret. Durin
On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura wrote:
> I have a fundamental question.
>
> While separating signature and payload by a dot "." seems ok,
> I still have not the answer for the question "why not make everything
> into JSON and base64url it?".
>
> i.e., Right now, you are proposing:
Makes sense. Personally, I don't have any preference on including it or not.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Campbell
> Sent: Tuesday, July 27, 2010 5:49 AM
> To: oauth
> Subject: Re: [OAUTH-WG] Proposed language
Right, Torsten has nailed this use case: it's not tied to unregistered
clients, though they could be useful there, too. We've seen need for
this in both an installed app (actually, a Java Web Start app) and a
server-based email gateway system. In both cases, one user can register
multiple instances
A client_id parameter would still be presented in the end user
authorization request. The text Brian E. quoted is what mandates any
specifications/documents/agreements that define how to use client
assertions must also define the association between the client_id and
some field(s) in the assertion.
If I understand your proposal correctly, you assume the clients knows
better than the authz server how to fit the client presentation
capabilities the best.
Wouldn't it be neccessary to also tell the authz server the screen
orientation and available size?
regards,
Torsten.
Am 12.07.2010 21:
I think the proposed parameters are useful for registered clients, too.
For installed applications, there is always the chance a user authorizes
the same application (==binary==client_id?) several times, every time on
a different device. It would be helpful to differentiate those copies.
regar
I have a fundamental question.
While separating signature and payload by a dot "." seems ok,
I still have not the answer for the question "why not make everything
into JSON and base64url it?".
i.e., Right now, you are proposing:
base64url_encode(JSON(payload,envelope)).base64url_encode(signature
26 matches
Mail list logo
