On Thu, Mar 15, 2012 at 15:43, Eran Hammer wrote:
> I don't know how to better explain myself. Forget about the text you have
> issue with. Just answer this:
>
> Reading the specification (with that text removed), what happens when a
> hybrid client wants to register? What client type does it pr
I don't know how to better explain myself. Forget about the text you have issue
with. Just answer this:
Reading the specification (with that text removed), what happens when a hybrid
client wants to register? What client type does it provide? How should the
server handle this case?
EH
> -
On Thu, Mar 15, 2012 at 13:13, Eran Hammer wrote:
> Ok. That's much better than my guess that you wanted to drop all the
> registration text from the specification…
>
> What I'm looking for is a simple text that answers the question:
>
> "What to do if my client isn't simply public or confidential
Ok. That's much better than my guess that you wanted to drop all the
registration text from the specification…
What I'm looking for is a simple text that answers the question:
"What to do if my client isn't simply public or confidential?"
If we just drop the current text, the answer is implicitl
I am proposing the entire removal of:
"A client application consisting of multiple components, each with its
own client type (e.g. a distributed client with both a confidential
server-based component and a public browser-based component), MUST
register each component separately as a different clie
Which text in -25 are you proposing we remove exactly? I can't judge the
text below without the full context of where and how it is proposed in the
current document.
Also, you are ignoring my detailed analysis of the current facts. We have
two client types and the issue here is what to do with oth
My proposal is to remove any reference to registration (which is a red
herring and has raised all the problems we refer here) and refer to
client authentication instead.
Proposal:
"Clients may be implemented as a distributed set of components that
run in different security contexts. For instance,
Here are the facts:
1. The authorization server must know the client type in order to enforce
many of the requirements in the specification.
2. The requirement to provide a client type is not decorated with a MUST or
SHALL but that is implied.
3. The specification only defines two client t
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Wednesday, March 14, 2012 4:55 PM
To: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
... Considering OpenID Connect as a motivating use case for OAuth, SWD is the
one
Hello,
I have read the draft of OAuth 2 rev 2.25 for the first time, so some of
my comments may be useless.
Sorry in advance if some of them have already been discussed and I
didn't find it in mailing list archive.
I found a grammatical error on page number 6, row 12 'refered' I think
should
I disagree. The add-on is necessary exactly because several OAuth experts
(Breno, Marius, Nat, John, Nov, and I) all read the new text as a breaking
change that prohibited exactly what the new text explicitly allows. Given you
agree that it doesn't change the meaning, there's no harm in adding
On Thu, Mar 15, 2012 at 07:45, Eran Hammer wrote:
> This add-on is unnecessary. It already says the authorization server can
> handle it any way it wants. The fact that other registration options are
> possible clearly covers the client identifier reuse case. As for the
> response type, that’s no
I believe most do, except for the dynamic client registration. I don't have
strong objections to it, but it is the least important and least defined /
deployed proposal on the list. The AS->RS work is probably simpler and more
useful at this point.
EH
> -Original Message-
> From: oauth
The only reason it is taking a long time is lack of WG feedback and total lack
of attention from the chairs. If you are looking to improve delivery time, I
would start by getting more involved and help drive issues to completion.
Suggesting the problem is with the single author is unfounded and
This add-on is unnecessary. It already says the authorization server can handle
it any way it wants. The fact that other registration options are possible
clearly covers the client identifier reuse case. As for the response type,
that's not an issue but more of an optimization for an edge case r
Agree that they are separate. For the use case I gave the fundamental requi
Sent from my iPhone
On 2012-03-15, at 9:22 AM, "Richer, Justin P." wrote:
>> 4) wrt revocation, we definitely see use cases (enterprise employee is
>> issued long lived refresh token for a mobile SaaS app, then gets f
4) wrt revocation, we definitely see use cases (enterprise employee is issued
long lived refresh token for a mobile SaaS app, then gets fired and so
enterprise needs to turn off the access) but can probably achieve the
equivalent with a SCIM 'delete user' message
Token revocation and user dele
Hi Hannes, happy to submit as ID once possible.
Wrt the current 5, we want them all (and more) :-) but the following are
data points for our prioritization
0) JWT is a given
1) we have implemented the SAML bearer token profile, somewhat
deprioritizing for us in the immediate term the equival
Hi Blaine,
These are indeed good requirements you stated below.
When you look at the list of topics do you think that the proposed items indeed
fulfill them?
Ciao
Hannes
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of ext Blaine Co
On 14 March 2012 20:21, Hannes Tschofenig wrote:
> So, here is a proposal:
>
> [Editor's Note: New work for the group. 5 items maximum! ]
>
> Aug. 2012 Submit 'Token Revocation' to the IESG for consideration as a
> Proposed Standard
> Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for
In Connect it is mostly the client that introspects the token, though we do use
JWT to keep things stateless.
As we move to more complex environments where clients are getting multiple
tokens from a AS for RS and those RS are decoupled from the AS, we need to
talk about JWT and introspection.
Hi Paul,
Interesting stuff. Thanks for sharing your draft writeup with us.
Could you submit the document as Internet Draft when the submission
gates open again?
The I-D submission tool will be reopened at 00h UTC, 2012-03-26.
>From the current list of items what do you consider less
To Eran's point about the relevance of RS-AS standardization in internal
vs external deployments, many of our customers are using our AS to issue
tokens to their API clients, but an API management solution (from
different vendor) to front their APIs.
The API management soln becomes the RS and
+1 to RS-AS OpenID Connect takes a slightly different approach to Paul's. The
fact that people are reinventing the same wheel, indicates it has
standardization potential.
John B.
On 2012-03-15, at 6:35 AM, Paul Madsen wrote:
> +1 to defining RS-AS interactions. We've implemented such a 'toke
That seems to cover it.
My problem is that client registration has been treated largely as being out of
scope other than some general principals. We are now adding normative text,
but still not specifying mechanisms.
Nat's text allows existing practice with complex clients like Facebook with
+1 to defining RS-AS interactions. We've implemented such a 'token
introspection' endpoint in our AS and I'm be happy to no longer need to
explain to customers/partners why it's not part of the standard.
As input, an (incomplete) spec for our endpoint enclosed. (we modeled
the verification as
Hi Mike,
The comment I sent to Nat applies here too. Something else has to be
dropped if we add another items.
To respond to Eran's remark I will talk to the APPs ADs to figure out
whether OAuth is the right place to do this work. There are various
considerations that matter, including
Hi Nat,
We currently have 5 new items proposed for the new charter. That's quite
a lot and I expect resistance from the IESG (given our previous history
of being somewhat slow with our work).
If you want a new item something else has to be dropped instead.
Anything you do not find as impo
Thanks for the info, Barry.
I would, however, like to find an additional co-author from the group to
ensure accelerated process
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of ext Barry Leiba
> Sent: Wednesday, March 14, 2012 10:25 PM
>
So, Eran's first proposal:
A client application consisting of multiple components, each with its
own client type (e.g. a distributed client with both a confidential
server-based component and a public browser-based component), MUST
register each component separately as a different client t
Looks good but I would like the group to consider the capability of signing
the request to be added.
See http://tools.ietf.org/html/draft-sakimura-oauth-requrl-01
It basically adds capability of signing the request in the form of JWS.
=nat
On Thu, Mar 15, 2012 at 7:51 AM, Anthony Nadalin wrot
31 matches
Mail list logo
