Hi all,
We were discussing the possibility to use Oauth2 token on SOAP in our product.
The preferred way in mentioned in RFC is of course to put it to HTTP
Authorization header, but in this case it will beyond the scope of SOAP stack
and I am not sure it shall be the correct way to go.
> -Original Message-
> From: Richer, Justin P. [mailto:jric...@mitre.org]
> Sent: Wednesday, March 14, 2012 7:51 PM
> [...] the AS-PR connection is a real and present known
> gap introduced in OAuth2 (since OAuth1 didn't even think of them as
> separate entities) and *somebody* should be
Makes sense to limit the scope within this WG and try to spin new ones where
appropriate for other work (or find homes in others). We wouldn't want the
OAuth WG to just be a convenient hanging-point for vaguely related things. That
said, the AS-PR connection is a real and present known gap intro
I'll be there to help support this part of the discussion as well.
-cmort
On 3/14/12 3:49 PM, "Brian Campbell" wrote:
Unfortunately I will not be in Paris for the Thrus meeting but I'd
love to see the assertion drafts progress. So thanks to Hannes for
putting it on the agenda and to Mike for o
Unfortunately I will not be in Paris for the Thrus meeting but I'd
love to see the assertion drafts progress. So thanks to Hannes for
putting it on the agenda and to Mike for owning that portion of it.
There's been some light discussion on this list around the assertion
stuff but, as far as I know
Agree contents looks good
Sent from my Windows Phone
From: Igor Faynberg
Sent: 3/14/2012 4:26 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
Looks good and comprehensive to me.
Igor
On 3/14/2012 4:21 PM, Hannes Tschofenig wrote:
> So, here
The best way is to get some drafts going and then revisit after the proposed
charter is completed. I think the 5 new items limit along with the existing
work is as much as this WG can take for the time being.
Getting some market experience would be great too.
EH
> -Original Message-
>
Methods of connecting the PR to the AS are something that several groups have
invented outside of the OAuth WG, and I think we should try to pull some of
this work together. OAuth2 gives us a logical separation of the concerns but
not a way to knit them back together.
Proposals for inclusion i
I am strongly opposed to SWD being part of *this* working group. My objection
is based on:
1. This is clearly an APP area document, not a SEC area document. Getting
this work done through the OAuth WG will skip the most relevant audience for
this document as a general purpose tool.
2.
I'll see this one through. I have some open issues to sum on the list shortly
which prevented me from getting a new draft submitted in time. Overall, we're
pretty much done and in agreement. The next draft which should not be a major
change, will be ready for WGLC. We can have this sent to the I
This is missing Simple Web Discovery, which there was substantial support for
including during the rechartering discussion in Taipei. Considering OpenID
Connect as a motivating use case for OAuth, SWD is the one spec that would then
be missing for this OAuth use case.
Please add it to the list
> Off list.
Or not so much off list. He-he.
b
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Off list.
> It would be great if people could just reply stating which they like best.
כן
Sometimes, one just has to whack people over the head.
b
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I've proposed two alternative languages and open to more. It would be great if
people could just reply stating which they like best.
EH
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Barry Leiba
> Sent: Wednesday, March 14, 2012 1:20 PM
Looks great!
Not sure if 'JSON Web Token (JWT)' belongs on this list, but not a big problem.
EH
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Hannes Tschofenig
> Sent: Wednesday, March 14, 2012 1:21 PM
> To: oauth@ietf.org WG
> Subjec
Looks good and comprehensive to me.
Igor
On 3/14/2012 4:21 PM, Hannes Tschofenig wrote:
So, here is a proposal:
---
Web Authorization Protocol (oauth)
Description of Working Group
The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access
Oh, and...
> 4. MAC Token (TBD)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/
I believe that in Eran's last communication about this he said that he
does, after all, have the time and inclination to finish it, and would
like to.
b
__
Looks good to me. One note:
> 2. OAuth Threats Document (Torsten)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/
I have been terribly remiss on this, so here's the thing:
- We have completed WGLC on this, and are awaiting my shepherd review
(which will include a recommendat
So, here is a proposal:
---
Web Authorization Protocol (oauth)
Description of Working Group
The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials
> I am sorry, but with this language this is a different spec with
> different compliance profiles and without supplying enough guidance
> for creating interoperable server implementations for common
> deployment models.
As I read this thread, I see two things come out clearly:
1. Eran didn't int
Feedback appreciated!
Web Authorization Protocol WG
=
THURSDAY, March 29, 2012
1300-1500 Afternoon Session I
Room: 252A
Chairs: Hannes Tschofenig & Derek Atkins
1. Agenda Bashing, WG Status
(+ Welcome Derek and Thank You Barry)
2. OAuth Threats Document (Torsten
On Wed, Mar 14, 2012 at 12:23, Eran Hammer wrote:
> Let's take a step back for a second.
>
> Previous versions of this document stated that during the registration
> process the client developer specifies the client type as described in 2.1.
> This has been specified under "registration requirem
Even though I also don't like the addition of normative text in such a late
revision, I'm with Eran in that I don't think this actually introduces a
breaking change, nor did I read it as such when it went through. It's talking
about public vs. confidential clients and keeping them separate, and
Let's take a step back for a second.
Previous versions of this document stated that during the registration process
the client developer specifies the client type as described in 2.1. This has
been specified under "registration requirements" since -17 published July 8th
2011. The only two types
All of Marius, Breno, Nat, myself, and several others on the OpenID AB list
have read it this way. I believe that either this change needs to be removed
(my preference!) or a sentence needs to be explicitly added that states that
"The same client_id MAY be used with both the code and token resp
You are not reading it correctly.
This is a *registration* requirement, meaning, the client has to inform the
server of the different components. If the server doesn't care, it can issue
one client identifier capable of both.
This protocol assume the authorization server asked the client for it
Before v23 a web server client could use either response_type=code or
response_type=token, with the same client id. No security issues and
this was supported for quite a while.
With this latest change, if I am reading it correctly, this is not
possible anymore. The client has to use two different
If the server locks a client type to a particular grant type (or response type)
then this is true, you don't need to specify the response type in the request.
But this is based on a very limited set of potential response types. I can
envision a code response type with different response syntax b
Can you explain to me why response_type is necessary at all after this change.
If a javascript client (candidate for token usage) and the web server
component (candidate for code usage) cannot share registration (since
they are different components with different security contexts of the
same appl
This was already raised and addressed on this list last week.
When someone defines and registers code+token, that specification must define
how such a client is registered in light of the text below. This might mean
defining a new client type, choosing the confidential client type with other
no
Hi,
Nat Sakimura started a thread on the OpenID Connect list about a
breaking change introduced by rev 2.3
The paragraph in question is in section 2.1:
"A client application consisting of multiple components, each with its
own client type (e.g. a distributed client with both a confidential
serve
Thank you for your reply. We've indeed decided to go with the
authorization flow like you suggested, because:
- the client credentials flow would require a timeout for user
registration (to handle idle users)
However, it seems that you might as well use the authorization flow in
that case,
32 matches
Mail list logo
