Yes but the two of us going back and forth seem not to be making progress.
I am still at the IDESG meeting if you want to get together.
On 2013-05-09, at 5:19 PM, Phil Hunt wrote:
> Well this is a last call discussion. So we have to get somewhere don't we?
>
> Phil
>
> On 2013-05-09, at 16:55
Well this is a last call discussion. So we have to get somewhere don't we?
Phil
On 2013-05-09, at 16:55, John Bradley wrote:
> The downgrade is at runtime not at registration. It is signalling the
> methods the RP doesn't want the AS to support for the client_id.
>
> We are not getting anywh
The downgrade is at runtime not at registration. It is signalling the methods
the RP doesn't want the AS to support for the client_id.
We are not getting anywhere on this. The parameter is required for dynamic
registration of higher security clients at AS that support multiple
token_endpoint
Maybe i am not being clear. I feel the parameter must not be in the dyn reg
request. The parameter should be in the response so that the client has no
choice and no ability to downgrade.
Phil
On 2013-05-09, at 16:37, Phil Hunt wrote:
> How does NOT allowing clients to choose authn type allo
The client auth type parameter issue needs to be resolved.
Phil
On 2013-05-09, at 16:23, John Bradley wrote:
> I believe the spec is fine as is.
>
> John B.
>
> On 2013-05-05, at 11:50 PM, Hannes Tschofenig
> wrote:
>
>> This is a Last Call for comments on
>> http://tools.ietf.org/html/dr
How does NOT allowing clients to choose authn type allow them to downgrade. I
am saying there is NO value in allowing this and that the parameter needs to be
removed.
Phil
On 2013-05-09, at 16:03, John Bradley wrote:
> The issue is not allowing fake clients to dynamically downgrade, where th
I believe the spec is fine as is.
John B.
On 2013-05-05, at 11:50 PM, Hannes Tschofenig wrote:
> This is a Last Call for comments on
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10
>
> Because of the timing of the impending Internet Identity Workshop we are
> setting the call for **3
The issue is not allowing fake clients to dynamically downgrade, where the AS
supports multiple methods.
On 2013-05-09, at 3:58 PM, Phil Hunt wrote:
> You seem to now be talking about SAML endpoints rather than OAuth endpoints.
>
>
> I think you are confusing what the client gets back from t
You seem to now be talking about SAML endpoints rather than OAuth endpoints.
I think you are confusing what the client gets back from the AS in terms of the
OAuth protocol vs. how the client authenticates to the AS. The parameter in
question isn't about what assertions the AS returns to the c
Consider if you will a world where IdP support multiple LoA.
This allows a RP to register the method required for there use case.
If a Client requires the asymmetrically signed JWT assertions rather than http
basic, it doesn't want the Authorization server accepting http_basic for it's
client_
Giving the client the choice lets the client choose lower LoA and downgrade.
Surely it is the server that is taking the risk so the server has the right to
set the requirements.
Why would a server tolerate multiple levels of LoA from the same client
application? Why is that needed?
If a serv
The client needs to be able to say only use a particular auth method to
disallow the Authorization server from providing a weaker method to an
attacker.
This is a required parameter to allow a Authorization server to support high
and low LoA clients dynamically.
John B.
On 2013-05-09, at 2
Part of my argument for leaving this parameter in is exactly the use case that
you're saying: the client doesn't tell the server anything but the server tells
the client what it must use to authenticate. That's already possible using
what's there. But I'm loathe to pull out this particular piece
I believe that the spec is fine either as-is, or with the addition of a
registry for token_endpoint_auth_method values. I'd slightly prefer the
registry but wouldn't object if it were not added.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [ma
Justin,
Just to progress towards resolving this issue, what I would like to understand
is how specifying authentication type makes things simpler or more
inter-operable. I'm concerned that the logic you proposed early in the thread
is a lot more complexity. I would prefer just having the serve
So if that's the case -- you've got a client that can't keep a secret that has
a secret -- you do one of the normal auth methods (like client_secret_basic)
and call it a day. I don't think it makes any sense, and the language below is
really less about client secrets and more about assertions an
Hi Antonio,
this parameter is supposed to show how the extension points works.
Here is the text from the draft about how these extensions are supposed
to work:
Collision Resistant Namespace A namespace that allows names to be
allocated in a manner such that they are highly unlikely
Hi *,
the example plaintext in the JWT specification [0] has a "weird" JWT claims Set:
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
The "http://example.com/is_root":true part looks a bit odd to me. Is it a typo?
Regards
Antonio
[0] http://tools.ietf.org
18 matches
Mail list logo
