I'm willing to do 5 minutes on the status of the Core and Bearer documents.
I'm willing to give an update on JWT and the JWT Bearer - probably 15 minutes.
It's probably good that we're a day after the JOSE WG meeting, given the JWT
dependency upon the JOSE specs.
I'm willing to be part of a di
The more I think about this the more I think that HoK is really more or an
informational type RFC if anything. If you really want a cleartext part so as
not to encrypt a certificate or something then OK, but in the end all our
extant token types can support the HoK token payload. In profiles w
I agree that we don't want things like Internal Server Error (500) duplicated
in OAuth specific errors. The only thing I might add to 5.2 is something like
"Other HTTP status codes such as 500 (Internal Server Error) may be returned
with no OAuth specific parameters."
-bill
_
4.2.2.1 and 4.1.2.1 are error codes that are returned to the client through the
browser via a 302 redirect.
You can't send a 5xx error via a 302 redirect.
That is why those need error messages specific to OAuth.
Errors not being sent via redirect use normal http error codes.
I thought that w
I think having the proof in the token works for SAML and JWT.
I would like to also allow for an opaque token that the RS may deference to get
the key.
John B.
On 2012-07-13, at 10:40 AM, Phil Hunt wrote:
> At the moment there is no hok proof in the token itself. It seems to be bound
> in tls.
At the moment there is no hok proof in the token itself. It seems to be bound
in tls.
The spec isn't clear yet that a token is passed in 3.2. But I assumed that is
what Hannes intended.
Still since there is no comment about passing the token I guessed it would
essentially be a bearer token b
I am not saying it is unusual in a bad way.
Some people think of TLS client auth happening at the TLS layer. That is
common in server to server connections.
Decisions based on the client cert can happen at the app layer, as they do in
SAML HoK.
I think people have less experience with doing
Hi John,
authorization decisions are not made by the TLS library - they are made by the
application.
For example, in the HTTPS case the authorization decision that is made by the
client is to compare the content of the cert with the domain part of the HTTP
URI. Similar authorization decision
It sucks for TLS hinting:)
In principal the client needs to know what keypair to use for the TLS session
before it is initiated.
The protected resource establishes the session with client auth accepting any
client key.
The protected resource compares the client key passed in from TLS with the
Hi James,
>
> So the OAuth client completes a TLS handshake with a protected resource using
> a raw key, but the protected resource doesn't get any authorization for that
> raw key until it sees an access_token which appear where? In an HTTP header
> somewhere in the App Data some time after
FRom what I can see in a similar discussion Eran pointed out that this is a
direct communication, communication between the client and token endpoint.
Server Error and temporarily unavailable are not OAuth specific and are handled
by existing HTTP error codes.
I don't see a need for a change.
Hi all,
for our conference call next week Nat offered his conference bridge (since we
had some problems with Google+).
Date: 16hh July 2012 (Monday)
Time: 1pm EDT
Agenda: We will do a status check on these documents:
*draft-ietf-oauth-v2
*draft-ietf-oauth-v2-bearer
*draft-ietf-oau
Hi Charles, Dick
I think this has been already discussed in [0]
Regards
Antonio
[0] http://www.ietf.org/mail-archive/web/oauth/current/msg08261.html
On Jul 13, 2012, at 2:09 AM, Dick Hardt wrote:
Charles
Thanks for the suggestion. I just did publish a new draft that included a
number of ite
13 matches
Mail list logo
