I definitely like the idea of an Errors section that normatively defines
error responses.
Thanks,
George
On 1/11/13 1:04 PM, Richer, Justin P. wrote:
It should follow the 6749 Token Endpoint error responses for bad
client credentials. That's what this text at the end of 2.3 is
supposed to m
It should follow the 6749 Token Endpoint error responses for bad client
credentials. That's what this text at the end of 2.3 is supposed to mean:
If the client credentials are invalid or there is another error, the
Authorization Server responds with the appropriate error response
from t
That text around audience in the framework spec changed from a SHOULD to a
MAY in -09 so that it would be more consistent with the the SAML and JWT
versions, which were already using a MAY in that context.
Your concern is valid Hannes and your point is taken. But reality is rather
messy and I don'
Additional feedback on the introspection endpoint.
What is the expected error response if the introspection endpoint is
using client credentials as recommended in section 2.1
The endpoint SHOULD also require some form of authentication to
access this endpoint, such as the Client Authenticat
Thanks for the thorough writeup, this is definitely an interesting use case.
There are a few ways that you could go about this, from what I'm seeing, but
there are also some things to untangle first. My apologies for the wall of text.
First, public clients can keep secrets, but there's a differe
Hi Justin,
see below.
On Jan 11, 2013, at 4:34 PM, Richer, Justin P. wrote:
> Hannes, thanks for the input. Inline:
>
> On Jan 11, 2013, at 4:33 AM, Hannes Tschofenig
> wrote:
>
>> Hi Justin,
>>
>> thanks for the input.
>>
>> A few minor remarks inside:
>>
>> On Jan 4, 2013, at 12:45 A
Yes in assertions it needs to be general. It is the JWT and SAML profiles that
need to nail down what the format of the audience is.They should probably
both be the URI of the token endpoint. In both SAML and JWT there can be
multiple audiences for the token.
John
On 2013-01-11, at 11:37
If that's the case then I would omit the RFC 2119 language and say that the
details have to be provided by the respective documents.
On Jan 11, 2013, at 4:37 PM, Richer, Justin P. wrote:
> It's my understanding that the general assertions claim is more of a
> conceptual mapping than it is a co
It's my understanding that the general assertions claim is more of a conceptual
mapping than it is a concrete encoding, so anything more specific here would be
out of place. I would like the authors to either confirm or correct my
assumptions, though.
-- Justin
On Jan 11, 2013, at 6:30 AM, S
Hannes, thanks for the input. Inline:
On Jan 11, 2013, at 4:33 AM, Hannes Tschofenig
wrote:
> Hi Justin,
>
> thanks for the input.
>
> A few minor remarks inside:
>
> On Jan 4, 2013, at 12:45 AM, Justin Richer wrote:
>
>> I'd like to present two use cases for signed tokens, for input into
Because they get redirected back to the client with an Authorization Code which
is then verified at the Token Endpoint without the User Agent's involvement.
Sure, the User Agent could have just made something up, but then it wouldn't
work at the Token Endpoint.
-- Justin
On Jan 11, 2013, at 4
Sent from BlackBerry® on Airtel
-Original Message-
From: oauth-requ...@ietf.org
Date: Fri, 11 Jan 2013 09:33:29
To:
Subject: OAuth Digest, Vol 51, Issue 41
If you have received this digest without all the individual message
attachments you will need to update your digest options in you
Hi,
Since we thought we were done with it, I put this document
on the IESG telechat agenda for Jan 24. Hannes' question
however looks like its a real one that needs an answer.
I'd appreciate it if the WG could figure out if there's any
change needed and either make that change in the next week,
Hi Justin,
thanks for the input.
A few minor remarks inside:
On Jan 4, 2013, at 12:45 AM, Justin Richer wrote:
> I'd like to present two use cases for signed tokens, for input into the
> ongoing MAC/HoK/higher-security discussion. Both of these are actual cases
> that I've done in the past,
Justin Richer 写于 2013-01-10 01:38:06:
> Brent,
>
> If you're sending the code in the back channel directly to the Client,
> as I believe you're doing from your text below, I would like you to
> realize some things:
>
> 1) This is not OAuth, and is in fact antithetical to the OAuth way of
> solv
The challenge is that we project an environment where there could be thousands
of applications conforming to a particular API (see
http://wiki.siframework.org/ABBI+Pull+Workgroup), with thousands of data
holders making data available through those APIs, and several authorizers (in
the OAuth 2.0
Hi Leif,
thanks for the timely review.
On Jan 2, 2013, at 1:52 PM, Leif Johansson wrote:
>
> Some comments in the order I discovered them...
>
> - the term holder-of-_the_-key (my ascii-emphasis) is used when
> the normal terminology is just "holder-of-key", not sure what is
> added by the de
Hi guys,
Thanks for updating the assertion document and for incorporating the comments
received on the mailing list.
There is only one issue that caught my attention. You changed the description
of the audience element to the following text (in version -09 of
http://tools.ietf.org/html/draft
Thank you Torsten for updating the document.
Two issues have been raised:
1) Terminology: Authorization vs. access grant vs. authorization grant
There is a little bit of email exchange on that topic:
http://www.ietf.org/mail-archive/web/oauth/current/msg10426.html
I personally don't have an op
19 matches
Mail list logo
