To directly address the 3 issues in Brian C's summary:
1) I haven't seen any strong use-cases for the issuing of refresh tokens
either, but we do find the SHOULD NOT language to be strong enough.
2) We support client_id being optional, and will have need for it.No
support for mandatory, nor
e
> assertions for both AuthN and AuthZ.
>
>Yaron
>
>> -----Original Message-
>> From: oauth-boun...@ietf.org <http://oauth-boun...@ietf.org>
>> [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Brian Eaton
>> Sent: Wednesday, July 07, 2010
Agree, good summary Brian C
I still haven't seen the use case for refresh tokens with assertion flow!
We can control that server side but it is easier to just implement the spec
as is.
It seems insecure granting a refresh token with potentially longer life
than the assertion. Do people intent on
terns) ended up moving
> assertions from AuthN to AuthZ, which was actually a new (and useful)
> feature but as a consequence created a hole that didn't exist with WRAP when
> dealing with AuthN.
> >
> > So by putting in client_assertion/client_assertion_type and keeping
>
h
> AuthN.
>
> So by putting in client_assertion/client_assertion_type and keeping
> assertion/assertion_type we get the best of all worlds. We can now use
> assertions for both AuthN and AuthZ.
>
>Yaron
>
>> -Original Message-
>> From: oauth-b
on_type we get the best of all worlds. We can now use
> assertions for both AuthN and AuthZ.
>
> Yaron
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Brian Eaton
>> Sent: Wednesday, July 07,
n now use
assertions for both AuthN and AuthZ.
Yaron
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Wednesday, July 07, 2010 2:03 PM
> To: Eran Hammer-Lahav
> Cc: Hannes Tschofenig; OAuth WG
type we get the best of all worlds. We can now use
> assertions for both AuthN and AuthZ.
>
>Yaron
>
> > -Original Message-
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Brian Eaton
> > Sent: Wednesday, July 07, 2010 2
enig; OAuth WG
> Subject: Re: [OAUTH-WG] assertion profile changes
>
> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav
> wrote:
> > It is pretty much the same as originally proposed. Any recent changes
> > are an oversight, not any intentional change. Since it was pro
OK, I *think* I understand your use-case... Just to be clear, even
after your internal discussions, you don't see a need for a client
secret in this flow?
Our SAML endpoints encode the tenant in the URL like so:
https://www.google.com/accounts//acs
But I'd have no problem with supporting per te
Already is.
http://github.com/theRazorBlade/draft-ietf-oauth/raw/3e9a1e67807b7bbfe79ca4045a44b613ef45c990/draft-ietf-oauth-v2.txt
EHL
On 7/8/10 8:21 AM, "Justin Richer" wrote:
Would it help if the client_ stuff were dropped from the example in the
assertion flow? I'm in favor of it being allo
Would it help if the client_ stuff were dropped from the example in the
assertion flow? I'm in favor of it being allowed, but if the general use
case is going to be without it then the example should reflect that and
cut down on the confusion.
-- Justin
On Wed, 2010-07-07 at 18:01 -0400, Brian
On Thu, Jul 8, 2010 at 11:53 AM, Kris Selden wrote:
> The refresh token is key to separating concerns of the protected resource
> from the auth server.
>
> I think this is succinctly explained the original rationale (refresh token =
> refresh secret):
> http://wiki.oauth.net/ScalableOAuth#Append
The refresh token is key to separating concerns of the protected resource from
the auth server.
I think this is succinctly explained the original rationale (refresh token =
refresh secret):
http://wiki.oauth.net/ScalableOAuth#Appendix
On Jul 8, 2010, at 1:51 AM, Laurens Van Houtven wrote:
> J
Just pitching in as someone writing something that might want a
refresh token but *really* doesn't understand why he'd need them. They
make very little sense to me; why not just make the token that allows
you to access a protected resource last longer? Use case: we've got
protected resources that g
BTW, I'm not opposed to writing more detailed profiles based on the generic
framework provided by the two endpoints defined and theyr many optional
components. I think the new format helps clarify the overall architecture and
easier to implement a generic client for (given that all the parameter
Use-case: When establishing web federation with customers we allow
them to either use their salesforce username ( enforced to be globally
unique ) or a federationid ( enforced to be unique to that particular
customer/tenant ) as the subject of their SAML assertion. Since our
SAML ACS is global
On Wed, Jul 7, 2010 at 4:51 PM, Chuck Mortimore
wrote:
> This thread forced a great deal on internal discussion today, and we
> actually do have some more immediate use-cases where we'll require
> client_id with the assertion flow
>
> I support leaving it as optional
Can you describe the addition
This thread forced a great deal on internal discussion today, and we
actually do have some more immediate use-cases where we'll require
client_id with the assertion flow
I support leaving it as optional
-cmort
On Wednesday, July 7, 2010, Brian Eaton wrote:
> On Wed, Jul 7, 2010 at 2:52 PM, Eran
On 7/7/10 3:01 PM, "Brian Eaton" wrote:
On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav wrote:
> I disagree with this approach. There are plenty of optional parameters in
> the spec.
Yes. I think most of them are a bad idea.
> The assertion access grant requires further profiling to be usef
On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav wrote:
> I disagree with this approach. There are plenty of optional parameters in
> the spec.
Yes. I think most of them are a bad idea.
> The assertion access grant requires further profiling to be useful. This
> doesn’t mean it needs another s
I disagree with this approach. There are plenty of optional parameters in the
spec.
The assertion access grant requires further profiling to be useful. This
doesn't mean it needs another spec, but that when you use it, you need to
document clearly what is expected. When you do that, spell out w
On Wed, Jul 7, 2010 at 2:18 PM, Eran Hammer-Lahav wrote:
> On 7/7/10 2:02 PM, "Brian Eaton" wrote:
>> Can you point me to the e-mail threads that reached consensus on using
>> client authentication?
>
> This was requested a few months ago and was included in -05 as optional. I
> did not see any f
I'm currently finishing an extension spec for client-to-client access
delegation based on the assertion profile. I believe it will use the client
secret and return a refresh token, because the assertion is meant to be
temporary, at least in its current form. If the assertions are moving in a
I don't have time to go dig through the list archive.
On 7/7/10 2:02 PM, "Brian Eaton" wrote:
> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav wrote:
>> It is pretty much the same as originally proposed. Any recent changes are an
>> oversight, not any intentional change. Since it was propos
On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav wrote:
> It is pretty much the same as originally proposed. Any recent changes are an
> oversight, not any intentional change. Since it was proposed, the only
> change made (with full consensus) was to allow client authentication as an
> optional r
On 7/7/10 9:40 AM, "Brian Eaton" wrote:
> Hi folks -
>
> What is the story with the evolution of the assertion profile?
It is pretty much the same as originally proposed. Any recent changes are an
oversight, not any intentional change. Since it was proposed, the only
change made (with full c
Good catch Brian - client_id and client_secret now seem mandatory when reading
draft 9. When those were originally added to the flow, they were clearly
marked as optional. That is lost in the latest drafts.
We'd be happy with either optional or removed. Mandatory doesn't work for us
at al
Hi folks -
What is the story with the evolution of the assertion profile?
As far as I can tell, it keeps changing for no good reason. Everyone who
wants to implement the profile has the exact same requirements, and
agreed on how it should work a long time ago.
Here's the timeline:
- a bunch of
29 matches
Mail list logo
