On 9/13/10 8:24 PM, Thomas Hardjono wrote:
> Hannes,
>
> I strongly believe that SAML support in Outh2.0 and "SAML-interoperability"
> is crucial in getting Oauth accepted and deployed in high-assurance
> (high-value) environments (eg. government, financials).
+1.
> As such, if its ok with Bria
Your understanding is correct. I just wanted to note the additional data
required at the authz server in order to implement the indirect case.
Regards,
Torsten.
Am 15.09.2010 um 00:32 schrieb Brian Campbell :
> So is my understanding of the kraft incorrect? I read it to say that
> direct acc
Dynamic authz server discovery and client registration would be needed in
OAuth-based identity management. But I would submit that they're needed even
apart from it (since I've got that need), and so should be specified modularly,
with the identity management piece pointing to it (if it wants t
So is my understanding of the draft incorrect? I read it to say that
direct access token revocation is optional but, if supported, then all
associated assess tokens must also be revoked on a revocation of a
refresh token.
On Sun, Sep 12, 2010 at 4:13 AM, Torsten Lodderstedt
wrote:
> Stefanie,
>
It really depends on the requirements or policy of the authorization
server. For the I-D I've been working on,
https://datatracker.ietf.org/doc/draft-campbell-oauth-saml/, there's
nothing that binds of the assertion to the client. So there's not a
requirement for that enforcement nor is there rea
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
> 1. Evil user starts the OAuth flow on the client using the web-server flow.
> 2. Client redirects the evil user to the authorization server, including state
> information about the evil user account on the client.
> 3. Evil user takes the auth
Thanks Zachary,
> -Original Message-
> From: Zeltsan, Zachary (Zachary) [mailto:zachary.zelt...@alcatel-
> lucent.com]
> Sent: Tuesday, September 14, 2010 6:24 AM
> To: Thomas Hardjono; Faynberg, Igor (Igor)
> Cc: oauth
> Subject: RE: [OAUTH-WG] Delegation -- RE: SAML profile
> comments/q
I plan to work on that aspect. Do you (or someone else) want to contribute?
regards,
Torsten.
Am 14.09.2010 um 17:18 schrieb Mark Mcgloin :
> What about Security Considerations. I know some individuals have worked on
> it in the past - does it need a WG to complete
>
>
> Mark McGloin
>
> Han
What about Security Considerations. I know some individuals have worked on
it in the past - does it need a WG to complete
Mark McGloin
Hannes Tschofenig
Sent by: oauth-boun...@ietf.org
12/09/2010 00:59
Hi all,
at the Washington Internet Identity Workshop we had the chance to chat
about OAu
> Third, I think the implementers guide is absolutely essential.
> (Interestingly enough, the discussion of white spaces vs. commas in
> yesterday's thread has effectively started this work.) In my opinion,
> this item must be carried in parallel with others. I wonder if this
> should be tied
Thomas,
The draft does not specify a limit on the number of delegations from Client#N
to Client#(N+1).
The draft's revision would require a substantial work because the draft relies
on the community version of OAuth, which differs significantly from the current
OAuth v.2. I am talking with our
Hannes,
Many thanks for putting this together.
First, I strongly believe that the work that had already been identified
important and had started needs to be finished, and to this end I
consider the item that Torsten had brought forth, on *token revocation*,
to be of the highest priority. We
12 matches
Mail list logo
