Hi John,
At 12:54 18-02-2013, John Bradley wrote:
That is where we get into the area Stephen Farrell has been raising
about MTI not being required to deploy.
The topic of mandatory to implement has been discussed previously in
the working group.
Stephen Farrell explained [1] what it meant. Ba
The client_id value and the access token value are independent.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Lewis
Adam-CAL022
Sent: Monday, February 18, 2013 2:50 PM
To: oauth@ietf.org WG
Subjec
Is there any guidance on the usage of client_id when using the JWT assertion
profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes no mention so I
assume that it is not required ... but it would be necessary if using in
conjunction with a HOK profile where the JWT assertion is issued t
Thanks Barry,
We had to partially roll our own registration spec because there was no common
one at the time. We did however partially base ours on the UMA one and now we
have sever groups working on
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ based on
implementation experience
>or non-existent. Note that for security reasons, to inhibit brute force
>attacks, endpoints MUST NOT return 404 Not Found error codes.
>
>From a security point of view differentiating the two is bad as it
>helps an attacker find valid notes to brute force. Ideally you want an
>attacker to spen
I do believe some face to face discussion amongst a smallerish group might
be valuable on this. I'll be in Orlando and plan on contributing to that as
much as I can. Thanks for organizing the lunch discussion Stephen.
I do feel that this conversation has strayed a bit and I'd like to clear up
one
>
> "Dynamically declaring," in what sense? Where are those mechanisms
> documented?
>
> ** **
>
> Many of them are documented in draft-ietf-oauth-dyn-reg.
>
> ** **
>
> One profile (an outer doll J) that enables fully interoperable
> implementations is documented in draft-hardjono-oauth-u
>
> It seems like the scope of your criticism has more to do with RFC 6749 &
> RFC 6750 overall, than the assertions drafts themselves.
>
No, and I'm sorry if it came across that way. I mentioned the token-type
issue only by way of background. As it happens, I do think it was a
mistake to publis
"Dynamically declaring," in what sense? Where are those mechanisms documented?
Many of them are documented in draft-ietf-oauth-dyn-reg.
One profile (an outer doll :)) that enables fully interoperable implementations
is documented in draft-hardjono-oauth-umacore. It uses the
"http://docs.kanta
I'll get to John's message later, after I digest it more. I can reply to
this one now.
please explain how you and I can each write applications to that?
>
> **
>
> ** **
>
> You can write applications to that by having the profile chain end, and
> with the contents of the Audience field being com
Hi Barry. Thanks for your response. I believe we share the same goals here
(the "what"). Where I think we need to focus the discussion then is on the
mechanisms to achieve that (the "how"). Let me fill in the details, as I see
them, by responding to a few things you wrote:
If you do this
On 18/02/13 16:54, John Bradley wrote:
A base64url decoder doesn't need the padding bytes in this case. They are
really only useful if you are concatenating outputs together. The number of
missing pads characters can be calculated from the number of base64url encoded
octets to be decoded.
A base64url decoder doesn't need the padding bytes in this case. They are
really only useful if you are concatenating outputs together. The number of
missing pads characters can be calculated from the number of base64url encoded
octets to be decoded.
So the padding and any other line wraps S
Hi,
RFC4648 [1] says:
"The pad character "=" is typically percent-encoded when used in an
URI [9], but if the data length is known implicitly, this can be
avoided by skipping the padding; see section 3.2."
while the SAML2 Bearer token draft says:
"The SAML Assertion XML data MUST be encoded
+1 to avoiding suspend
"I don't think it's worthwhile to specify it as a "suspend" operation,
because to me "suspend" implies an ability to "unsuspend", and I really
don't think we want to get into the complicated zombie OAuth client
business."
Sal
Salvatore D'Agostino, CSCIP
IDmachin
inline
On 2013-02-18, at 11:31 AM, Justin Richer wrote:
>
> On 02/17/2013 05:54 AM, Torsten Lodderstedt wrote:
>> Hi Justin,
>>
>> the new revision seems to catch the state of discussion and is consistent.
>> Thank's for bringing this topic forward.
>>
>> On your editor's not in section 4.2.:
Barry,
I will point out that in RFC 6749 the Client is specificity not required to
understand the access token, it is required to understand the token_type in the
response from the authorization server in order to know how to present the
token to the RS.
Perhaps you were speaking metaphoricall
On 02/17/2013 05:54 AM, Torsten Lodderstedt wrote:
Hi Justin,
the new revision seems to catch the state of discussion and is
consistent. Thank's for bringing this topic forward.
On your editor's not in section 4.2.: In my opinion, the 404 due to a
none-existing resource should precede the 4
The text in question refers to responses from the Token Endpoint,
whereas this spec deals with a separate endpoint, the Client
Registration Endpoint. Therefore, the text doesn't directly apply.
However, it's not bad advice to replicate that here since we are issuing
a special-use access token
Nat's attack vector presumes lack of logging on the server side, where
doing a "delete" means that you can no longer see anything about who did
what. You could make the same argument if you have a system where users
can register themselves and delete their accounts at will -- someone
creates a
Hi Barry,
I agree with you generally, but just on one point...
On 02/18/2013 05:38 AM, Barry Leiba wrote:
> That's why I say that as I see it, it's not an issue of MTI.
I do think there is an issue related to MTI that's affecting
the discussion. Clearing up that issue won't by itself solve
th
21 matches
Mail list logo
