If we were using PKCS#7 for certs, then why not PKCS#7 the payload as well?
(No - I am not proposing to do it. Doing so with AES-128,192,256 is
prohibitive in some language such as PHP, but just as a point of
discussion to close this.)
On Tue, Jun 22, 2010 at 6:33 PM, Ben Laurie b...@google.com
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)
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.
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
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
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
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 for
On Thu, Jul 22, 2010 at 3:39 PM, Torsten Lodderstedt
tors...@lodderstedt.net 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
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
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
On Tue, Jul 27, 2010 at 10:31 AM, Justin Richer jric...@mitre.org 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
On Tue, Jul 27, 2010 at 12:26 PM, Chuck Mortimore
cmortim...@salesforce.com 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
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
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, some of
On Wed, Jul 28, 2010 at 5:43 AM, Dick Hardt dick.ha...@gmail.com 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
On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz balf...@google.com wrote:
On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura sakim...@gmail.com 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
On Tue, Jul 27, 2010 at 3:35 PM, Nat Sakimura sakim...@gmail.com wrote:
On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz balf...@google.com wrote:
On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura sakim...@gmail.com
wrote:
I have a fundamental question.
While separating signature and
Hi.
Currently, the discovery document would have something like:
{
verification_keys: {
key1:RSA.ALqcwR...,
key2:X509.certificate
}
}
It defines RSA and X509. Could we define a third type certs_url that
points to the
file that stores PEM format
On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
bcampb...@pingidentity.com 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
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
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 e...@hueniverse.com wrote:
Is someone going to turn this into an I-D anytime soon?
EHL
From: oauth-boun...@ietf.org
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 e...@hueniverse.com wrote:
Is someone going to turn this into an I-D anytime soon?
EHL
From: oauth-boun...@ietf.org
22 matches
Mail list logo
