Hi Phil,
You would send the client's credential to the authz endpoint, so it would go
through the browser and would be exposed to other parties.
I agree with George and others. This is a topic different from dyn reg and
should be handled independently.
I personally consider assertions as me
Authz server and resource server need to agree on a token format. The client
never needs to interpret the token content. Since we are talking about clients,
where is the connection?
regards,
Torsten.
Phil Hunt schrieb:
>I think many of the parameters in dyn reg need to be specified in the
>
Not everyone has the time or inclination to follow and respond to all of this.
On Wed, Aug 28, 2013 at 10:01 AM, Anthony Nadalin wrote:
> So I guess we should have different specifications for different use cases to
> solve same requirements, I guess we should have done that we OAuth and not
>
+1
Best regards,
Don
Donald F. Coffin
Founder/CTO
REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA 92688-3836
Phone: (949) 636-8571
Email: donald.cof...@reminetworks.com
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, Au
On 28/08/13 17:51, John Bradley wrote:
We probably don't want this secret that is used as confirmation of the code to
be confused with a client secret that is bound to a client.
They are verified by different levels of the stack. One client_id may have
many instances all using different value
I think many of the parameters in dyn reg need to be specified in the statement
-- the main change is we're moving dyn reg parameters into the statement and
locking them down between instances. It keeps hackers from changing individual
instances and it minimizes state in per instance registrati
>Now maybe your way is the better way but why not let the market make that
>decision?
So what is the hurry to get the dyn reg specification out the door, if we have
the market data it will make the specification that much better. I agree that
most of this can be done today w/o any additional sp
That's what I'm trying to do. All I have been asking for is time to explore the
spec and to see how it can impact and simplify dyn reg -- which I believe is a
significant amount. It would be pre-mature at this point to move Dyn Reg
forward without exploring this.
I still believe dyn reg is ove
We probably don't want this secret that is used as confirmation of the code to
be confused with a client secret that is bound to a client.
They are verified by different levels of the stack. One client_id may have
many instances all using different values of the code proof of possession
simu
You can pass anything as a client_id. It just has to be accepted. That's the
point of us writing a draft here isn't it?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-08-28, at 9:45 AM, John Bradley wrote:
> That is my concern as well, sending an assertion to th
For the last time, I am not against standardizing software assertions. I
have no idea where you keep getting that idea from, considering how many
times I've publicly come out in support of it. I've even offered to help
edit a spec to bring the ideas to their full and proper fruition.
What I di
Sergey,
I agree, the text may still be a bit awkward. What I was trying to open the
door to is that some client may not actually want access to the resource in
question -- they just want to authenticate the user.
So, if the client has an empty scope, the AS could interpret that as an
authenti
That is my concern as well, sending an assertion to the authorization endpoint
requires a extension of OAuth to add another parameter or placing it in the
client_id which you can do now with the dynamic reg spec if the AS wants to.
Holding up client registration for something that will require
So why are you fighting so hard against standardizing software assertions?
You're affectively already using the solution for BB+.
The fact that a standardized initial_access_token eliminates most of the
registration endpoint seems to be your primary objection.
Phil
@independentid
www.indepe
Yes. A client could pass the software statement *directly* as its client
credential. Which is one of the *simple* solutions. 8-)
The other case is where the client instance needs its own credential as George
indicates. In that case it could swap the statement for a unique client
assertion.
P
Yes, that already works. And you could accomplish that with the current
dynamic registration spec, too -- it's just that client assertions were
deemed too-underspecified to include in the base draft, and nobody's
stepped up to offer a full writeup and extension of using other auth
mechanisms (o
The initial_access_token doesn't assume that it's from the local domain.
It merely assumes that the authorization server accepts the token, which
would be true in the UMA case due to the federation. It could also be
the exact same kinds of mechanisms that the software statement would use
to ach
On 28/08/13 17:33, George Fletcher wrote:
So I understand that you'd rather that OAuth doesn't require a
client_secret and that's fine. However, I don't think we should impose
that thinking on the rest of the world who have already implemented it
and have it working and scaling without issues. If
George,
It would be reasonable for a client to submit an assertion, and obtain its own
client assertion in return. This is very close to what is happening per 2.1,
2.2 of http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-06
In this case, the Software Statement is an authorization that is
On 28/08/13 17:20, Phil Hunt wrote:
This is the key problem with dyn reg.
You have to recognize software as distinct entities shared by clients as
instances. Statements can be by a developer, an organization or an api owner
that approves clients in the same way google or facebook does today.
George
That case can be solved with a simple assertion swap. We just have to profile
it.
Phil
On 2013-08-28, at 9:20, George Fletcher wrote:
>
> On 8/28/13 12:02 PM, Phil Hunt wrote:
>> Please define the all in one case. I think this is the edge case and is in
>> fact rare.
>>
>> I agree
This is the key problem with dyn reg.
You have to recognize software as distinct entities shared by clients as
instances. Statements can be by a developer, an organization or an api owner
that approves clients in the same way google or facebook does today.
The approval happens once per client
Hi,
can you consider replacing "tcs" and "tcsh" with "temp_client_secret"
and "temp_client_secret_hash" ? in OAuth2 we have "client_id",
"client_secret" (ex, in dyn reg), and having a temp variant of
"client_secret" called as "tcs" seems a bit cryptic to me :-), not a bit
issue though
Serge
I set up an auth server to protect my API, my users download a piece of
software that speaks the API to access their data. Where is my server
supposed to get the list of "approved" software classes from? Are you
assuming a central registry per API? Or is it going to be
provider-specific? If the
I think it makes perfect sense to have different spects for different
use cases to solve different requirements (and the requirements *are*
different -- you keep bringing up fully stateless registration and
that's just not a requirement for many people). The different specs can
(and should) use
Please define the all in one case. I think this is the edge case and is in fact
rare.
I agree, in many cases step 1 can be made by simply approving a class of
software. But then step 2 is simplified.
Dyn reg assumes every registration of an instance is unique which too me is a
very extreme p
So I guess we should have different specifications for different use cases to
solve same requirements, I guess we should have done that we OAuth and not
worked out common flows, patterns, parameters, etc. I have only seen 2-3
respond to the implementation status, once again people should post if
Except that folks are already actually implementing and using the spec,
and that all of the discussions around different specs are pretty
clearly pointing to different use cases and assumptions about the state
of the world.
Your arguments are invalid.
-- Justin
On 08/28/2013 11:49 AM, Antho
>Therefore I once again call for the WG to finish the current dynamic
>registration spec *AND* pursue the assertion based process that Phil's talking
>about. They're not mutually exclusive, let's please stop talking
I see no reason to continue to push finish the current specification when there
Except for the cases where you want step 1 to happen in band. To me,
that is a vitally and fundamentally important use case that we can't
disregard, and we must have a solution that can accommodate that. The
notions of "publisher" and "product" fade very quickly once you get
outside of the soft
Sorry. I meant also to say i think there are 2 registration steps.
1. Software registration/approval. This often happens out of band. But in this
step policy is defined that approves software for use. Many of the reg params
are known here.
Federation techniques come into play as trust approva
I have a conflict I cannot get out of for 2pacific.
I think a certificate based approach is going to simplify exchanges in all
cases. I encourage the group to explore the concept on the call.
I am not sure breaking dyn reg up helps. It creates yet another option. I would
like to explore how f
Just wanted to respond to one point:
> SHOULD around open registration
The reason behind that was to encourage wider adoption. If you don't
have to do any out of band or manual steps to get your client
registered, you're more likely as a developer to use it (in my view at
least), so I'd like
Hi all,
in case we need more conference call dates I took a look at the poll and the
following dates showed up:
- Tue, 3 September 2pm EDT
- Wed, 11 September 2pm EDT
- Thu, 12 September 2pm EDT
- Tue, 17 September 2pm EDT
- Wed, 18 September 2pm EDT
- Wed, 25 September 2pm EDT
- Thu, 26 Septem
Here are the conference bridge / Webex details for the call today.
We are going to complete the use case discussions from last time (Phil wasn't
able to walk through all slides). Justin was also able to work out a strawman
proposal based on the discussions last week and we will have a look at it
Hi John,
On 27/08/13 13:00, John Bradley wrote:
Typically native apps on smart phones use the code flow and a redirect_uri with
a custom scheme to redirect the browser back to the app with the query encoded
code.
The native app is a public client as it cannot keep a secret, unless it is
usin
Hi Phil,
A have a question, re:
"The authorization server MUST:
-Perform the normal OAuth2 authorization process,
-MAY elect not to request consent if no access token is to be
issued (i.e. this is an authentication only request),
"
This last statement confuses me, given that the Authen
Minor typo is in section 2,
"The Authentication Code Grant type is used in exactly the same manor
as the Authorization Code Grant Section 4.1 [RFC6749] and has the
same features and conditions. The *Authorization* Code Grant
extends..."
Cheers, Sergey
On 28/08/13 00:37, Phil Hunt wrote:
38 matches
Mail list logo
