We are taking multiple paths trying to find the best balance.
There is an effort to draft a new document describing client authentication
using assertions. That effort seems to expand to encompass all assertion
related business. I'm supportive of that approach. This document may or may not
swal
Brian Campbell wrote:
Currently (draft -16) client_id is listed as a required parameter for
access token request to the token endpoint for all grant types except
for extensions. In section 3 there is some disposition of the use of
client_id as a means of identification and then, in 3.2, a requ
So the separate document was already discussed in the design team and in the
meeting on Monday, the action item was given to look at creating a separate
document for assertion covering authentication and authorization.
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentit
Currently (draft -16) client_id is listed as a required parameter for
access token request to the token endpoint for all grant types except
for extensions. In section 3 there is some disposition of the use of
client_id as a means of identification and then, in 3.2, a requirement
that client authen
It's not exactly clear to me what that means.
Near the end of the interim meeting on Monday there was a specific
discussion that resulted in a TODO item to draft a 4.5.1 subsection.
That's what I've done here and I believe it captures the intent
discussed at the meeting. I've written a small prop
What you quoted below was the acceptable syntax. The Authorization Server and
the Resource Server still need to agree upon the semantics of the bearer token
exchanged.
-- Mike
-Original Message-
From: John Kemp [mailto:j...@jkemp.net]
Sent: Wednesday, M
You're correct that I misspoke. The Authorization Server and the Resource
Server must agree on the format of the token. Yes, it's opaque to the client.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of P
On May 24, 2011, at 4:04 PM, Mike Jones wrote:
> George, you are correct that resources and clients must agree upon the format
> of the bearer token to achieve interoperability. The means for achieving
> this agreement is out of the scope of this document.
I thought the means for achieving IOP
In our case they are tightly bound as the assertions (same assertion) will be
used for authentication and also to grant authorization as this is what was in
scope with WRAP, so not addressing the assertion authentication is an issue for
us and I assume others also.
-Original Message-
F
That is another way to approach it and I understand there has been
some talk about that lately. While there are admittedly some
commonalities between assertion based grants and an HTTP parameter
based client authentication extension point, I personally think that
lumping them together is unnecessa
Mike/George, can you clarify in what sense must a client and RS agree on
the format of a bearer token? Are they not opaque to the client, and so
their internal format irrelevant to it?
paul
On 5/24/11 4:04 PM, Mike Jones wrote:
George, you are correct that resources and clients must agree upo
11 matches
Mail list logo
