On Wed, Aug 4, 2010 at 10:04 AM, Torsten Lodderstedt
wrote:
>> So far no one has offered to work on the security consideration section
>> (Brian's draft is too far from the format I need to incorporate).
>>
>
> I could work on this topic, if Brian does not insist to do so.
> @Brian: What do you th
I hope to have some discovery draft to share shortly after the next core draft.
It would be very much in line with the discovery stuff from previous core
drafts before I took it out (-05).
As for WG process/focus, that's the job of the chairs to figure out. I have no
intention of drafting or ed
Yes.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of William Mills
> Sent: Wednesday, August 04, 2010 9:05 AM
> To: Torsten Lodderstedt
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] OAuth Discovery Requirements
>
> I'm assumin
Thanks for the clarification (Paul, Chuck and Brian), re-reading the
most recent draft makes the use-case pretty clear, not sure how I came
up with my own personal use-case in this instance (not enough coffee
probably...)
To me it seems that this is an instance of a SAML --> OAuth token
mappi
- Original Message
> From: Michael D Adams
> I thought that page in your idea was being served from the
> Authorization Server (not the Resource Server). If that's true, the
> cookie would be on the wrong domain.
It might be a problem if resource and authz servers are in differen
On Wed, Aug 4, 2010 at 10:20 AM, Oleg Gryb wrote:
> - Original Message
>> From: Michael D Adams
>> As Brian mentioned, the client-side component hosted on thirdparty.com
>> does get the access token in the User Agent flow. That means the
>> client-side script can access multiple prote
- Original Message
> From: Michael D Adams
> As Brian mentioned, the client-side component hosted on thirdparty.com
> does get the access token in the User Agent flow. That means the
> client-side script can access multiple protected resources (upload a
> photo, update the user's
Only in my head. But I do want to use a consistent definition for discovery
within SASL.
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Wednesday, August 04, 2010 10:02 AM
> To: William Mills
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OA
ideas. I still hope to get the discovery spec finished in the same timeframe,
but have no plans to author or edit any other draft.
Just to get this clear. Do you plan to author the discovery spec? And what is
the core spec's timeframe?
I have started to write the discovery spec, but work
I'm not familiar with SASL. So out of curiosity: What is the relation
between HTTP WWW-Authenticate headers and SASL?
regards,
Torsten.
Am 04.08.2010 18:05, schrieb William Mills:
I'm assuming that the WWW-Authenticate style will also be supported (because
I'm going to try to make sure it get
On Wed, Aug 4, 2010 at 8:45 AM, Oleg Gryb wrote:
> - Original Message
>> From: Michael D Adams
>> If> thirdparty.com never gets the access token, thirdparty.com can never
>> do anything on behalf of the user.
>>
> thirdparty.com never gets the access token in the scenario that Brian has
> From: Brian Eaton
> To: Oleg Gryb
> Cc: Michael D Adams ; oauth@ietf.org
> Sent: Wed, August 4, 2010 9:04:05 AM
> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?
>
> On Wed, Aug 4, 2010 at 8:45 AM, Oleg Gryb wrote:
> > thirdparty.com never gets the access token in the
- Original Message
> From: Luke Shepard
> If you want to send an access token directly to the server, we have the web
>server flow designed to do that. The JS redirect or Ajax call is just a more
>complicated way to send the token to the server. The user-agent flow is
>intended
I'm assuming that the WWW-Authenticate style will also be supported (because
I'm going to try to make sure it gets added). I specifically want this for
SASL discovery.
-bill
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> On Behalf Of Torsten Lodd
On Wed, Aug 4, 2010 at 8:45 AM, Oleg Gryb wrote:
> thirdparty.com never gets the access token in the scenario that Brian has
> described, becuase fragment that was sent by a service provider in Location
> header is not going to travel to the thirdparty.com server.
This is not quite true.
thirdpa
Absolutely, however, I believe the atomic units that make up the OAuth
profile spectrum have not properly taken into account the tidal wave
of DiSo interactions that are forth coming. Subsequently you can force
them into place and say "they work" but IMO will have a hard time
achieving adoption du
Good explanation, thanks Chuck.
On Wed, Aug 4, 2010 at 9:43 AM, Chuck Mortimore
wrote:
> Hi Prateek
>
> The use-case we were going for here is really more like a classic 2-legged
> oauth scenario. A company has an existing SAML web federation established
> with a service provider which is pr
Hi Prateek
The use-case we were going for here is really more like a classic 2-legged
oauth scenario.A company has an existing SAML web federation established
with a service provider which is providing SSO to it's users.They now want
to perform API based integration with the service pro
- Original Message
> From: Michael D Adams
> If> thirdparty.com never gets the access token, thirdparty.com can never
> do anything on behalf of the user.
>
thirdparty.com never gets the access token in the scenario that Brian has
described, becuase fragment that was sent by a serv
On Wed, Aug 4, 2010 at 9:08 AM, Prateek Mishra
wrote:
> Brian,
>
> it would probably help to clarify that you are proposing this as a
> additional or follow-on step to SSO implemented via the SAML web browser
> profiles (right?).
Actually no.
The similarities to SSO are mostly in the assertion f
On Tue, Aug 3, 2010 at 9:34 PM, Luke Shepard wrote:
> Hi Oleg,
>
> If you want to send an access token directly to the server, we have the web
> server flow designed to do that. The JS redirect or Ajax call is just a more
> complicated way to send the token to the server. The user-agent flow is
Prateek, I believe that here it is the SAML IdP that acts as OAuth
Client, not SAML SP - the point of the flow is to get the Assertion
(that the IDP would normally send through the browser) over to the SP
through an OAuth request/response exchange (in order to get an OAuth token)
paul
On 04/
Brian,
it would probably help to clarify that you are proposing this as a
additional or follow-on step to SSO implemented via the SAML web browser
profiles (right?).
Maybe some text could be added to the draft to make that explicit. This
is in contrast to more general token exchange scenario
+1
Brian's profile serves a distinct purpose. I don't see a problem with different
assertion profiles for using SAML with OAuth, especcially given the wide usage
of SAML.
Regards,
Torsten.
Am 04.08.2010 um 07:21 schrieb Eran Hammer-Lahav :
> The single assertion use case is well defined. If
Would it make sense to support two scenarios? (1) Discovery as described in my
original posting independent of "functional" requests. (2) Discovery for
unauthorized requests (WWW-Authenticate header).
The later might be a lightweight variant of the first scenario.
regards,
Torsten.
Am 02.08
Please see my reply to James's posting and contribute to the Discovery
requirements thread.
One think I want to point out: proxying the authz server may help during the
initial discovery. Once the Client obtained a refresh token, directly
discovering the tokens endpoint (or a revocation endpoin
>
>> In my opinion, this decision is up to the authorization server and not
>> the resource server. Or should both be possible? What do you think?
>
> Theoretically, the decision should probably be up to the authorization server.
> In practise, however, the decision should be *delivered* from t
27 matches
Mail list logo
