lto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Friday, January 14, 2011 10:45 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: Client Assertion Credentials
I would like to suggest we drop the client assertion credentials (-11 section
3.2) from the specification, and if neede
vity...]ZT4%3D&
client_assertion_type=
urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Friday, January 14, 2011 10:45 PM
To: OAuth W
value MUST be an absolute URI.
> client_assertion - REQUIRED. The client assertion.
> For example, the client sends the following access token request using a SAML
> 2.0 assertion to authenticate itself (line breaks are for display purposes
> only):
>
>
>
> POST /token H
n
Behalf Of Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:45 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: Client Assertion Credentials
I would like to suggest we drop the client assertion credentials (-11 section
3.2) from the specification, and if needed, publish it as a separate
specifi
n...@ietf.org>
[mailto:oauth-boun...@ietf.org]<mailto:[mailto:oauth-boun...@ietf.org]> On
Behalf Of Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:45 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: Client Assertion Credentials
I would like to suggest we drop the client assertion creden
drop it is just
poor practice.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Tuesday, January 25, 2011 6:11 PM
To: Anthony Nadalin
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Removal: Client Assertion Credentials
Scope was discussed in detail, including use cases and implementation
n...@ietf.org]> On
Behalf Of Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:45 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: Client Assertion Credentials
I would like to suggest we drop the client assertion credentials (-11 section
3.2) from the specification, and if needed, publish it as a
...@microsoft.com]
Sent: Tuesday, January 25, 2011 5:32 PM
To: David Recordon; hannes.tschofe...@gmx.net; Eran Hammer-Lahav
Cc: OAuth WG; Blaine Cook
Subject: RE: [OAUTH-WG] Removal: Client Assertion Credentials
Based on your logic then Scope, Client Password Authentication, etc, should be
removed. Not
-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Friday, January 14, 2011 10:45 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: Client Assertion Credentials
I would like to suggest we drop the client assertion credentials (-11 section
3.2) from the specificatio
Hammer-Lahav
Cc: OAuth WG; Blaine Cook
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials
Explicitly saying, "The assertion format, the process by which the assertion is
obtained, and the method of validating the assertion are defined by the
assertion issuer and the authorization s
tted for brevity...]ZT4%3D&
>
> client_assertion_type=
> urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
>
>
>
>
>
>
>
>
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
F%2Fclient%2Eexample%2Ecom%2Fcb
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Friday, January 14, 2011 10:45 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: Client Assertion Credentials
I would like to suggest we drop the client assertion cred
Hi Eran,
Hi all,
I would like to start a working group last call on the base specification soon
and the writeup in Section 3.2 about the Client Assertion Credentials is,
unfortunately, not ready yet. Particularly the missing security discussion
scares me.
Hence, I would encourage someone to
Not sure I agree. Yes shared secret But one may be long lived (permanent)
while the other may be good for minutes. If a server has both what then? I
suppose we could detect type in client_secret or do it by policy associated
with a client_id. Is that what is intended in the spec?
As you say "
Phil,
> What if strong authentication of client (between client and
> AM) happened OOB? Instead of passing a client_assertion, why
> not pass a client_token? In a sense we would be repeating
> the pattern for users and applying it to clients. A client
> use its own client_token to obtain access t
ll specification elsewhere.
>
> EHL
>
> From: Francisco Corella [mailto:fcore...@pomcor.com]
> Sent: Sunday, January 16, 2011 11:31 PM
> To: Eran Hammer-Lahav; David Recordon
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials
>
> I w
ready taken
care of.
Francisco
--- On Sun, 1/16/11, David Recordon
mailto:record...@gmail.com>> wrote:
From: David Recordon mailto:record...@gmail.com>>
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials
To: "Eran Hammer-Lahav" mailto:e...@hueniverse.com>>
Cc:
o
--- On Sun, 1/16/11, David Recordon wrote:
From: David Recordon
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials
To: "Eran Hammer-Lahav"
Cc: "OAuth WG"
Date: Sunday, January 16, 2011, 8:36 PM
Seems good enough to me. +1 to removing it so that it will become
*From:* Phillip Hunt [mailto:phil.h...@oracle.com]
> *Sent:* Saturday, January 15, 2011 12:52 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Removal: Client Assertion Credentials
>
>
>
> A strong client credential is needed in many cases. I
xtension mechanism for new parameters. Why is that not enough?
>
>
>
> EHL
>
>
>
> From: Phillip Hunt [mailto:phil.h...@oracle.com]
> Sent: Saturday, January 15, 2011 12:52 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Removal: Clien
. Why is that not enough?
EHL
From: Phillip Hunt [mailto:phil.h...@oracle.com]
Sent: Saturday, January 15, 2011 12:52 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials
A strong client credential is needed in many cases. I had assumed client
assertion
A strong client credential is needed in many cases. I had assumed client
assertion would fulfill this need.
Phil
Sent from my phone.
On 2011-01-14, at 22:45, Eran Hammer-Lahav wrote:
> I would like to suggest we drop the client assertion credentials (-11 section
> 3.2) from the specificati
I would like to suggest we drop the client assertion credentials (-11 section
3.2) from the specification, and if needed, publish it as a separate
specification for the following reasons:
1. The mechanism is under specified, especially in its handling of the
client_id identifier (when us
23 matches
Mail list logo
