Some comments:
> The endpoint MAY allow other parameters to provide further context to the
> query.
If the endpoint does not understand these the endpoint must ignore.
The only MUST in this specification is to return the "active" Boolean, but this
is still underspecified as there is no definit
Hannes,
Please update my e-mail to wimi...@microsoft.com and my affilliation to
Microsoft in the next draft.
Thanks,
-bill___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Per
https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-01#section-3.1,
keys can be represented as JWKs (which are JSON objects), so I think the draft
already does what you're asking for in that regard. If that's not what you're
asking for, maybe we can talk about it in person and
This can't be limited to JWE Compact Serialization, we have keys that use the
JSON binary serialization.
"cnf" seems underspecified, as this could be a JWK (but not it's not a MUST),
and thus I may understand "cnf" but only when used with a JWK and not some
other invented structure. So how do I
Clients that share a common client_id can't pre register. You need to be
doing per instance dynamic client registration for that to work.
Non confidential clients need to push a key with code, or have it provisioned
by the AS with the AT.
Sent from my iPhone
> On Mar 5, 2015, at 2:04 PM, H
Others will hate the idea as well for other reasons I expect.
If we leave introspection aside it might be a way to deal with other specs
going forward.
Sent from my iPhone
> On Mar 5, 2015, at 2:02 PM, Justin Richer wrote:
>
> And you're right that I *really* don't like this because it brea
Hannes,
You're on the right track: the "active" claim *is* effectively a top
level toggle, much like an error message would be. However, we're taking
the same approach that token revocation uses and returning an HTTP OK
response with the information inside instead of an HTTP error. This was
d
Actually, I am not sure my statement below is actually correct.
We need to distinguish the case where the client id is unique per client
software instance and when it isn't.
If the client id is shared by multiple client software instances then
how do we make sure that clients aren't uploading key
And you're right that I *really* don't like this because it breaks
existing implementations somewhat arbitrarily. Mike had suggested
something similar.
-- Justin
On 3/5/2015 7:48 AM, John Bradley wrote:
A middle ground, that perhaps no one will like is registering
application specific claim
A middle ground, that perhaps no one will like is registering application
specific claims in the JWT registry, but pretending them with a app namespace.
Eg
Int:active
That prevents people from stepping on each other with short names, and gives a
central place to look them up, without requi
I agree and this can be done in AUTH48.
On 03/05/2015 01:59 PM, Justin Richer wrote:
> Right, but do we need to say that in Dyn-Reg? That's really more of a
> problem for the protocol using the keys, not the one registering it for
> use.
signature.asc
Description: OpenPGP digital signature
In context of we then need to
differentiate the case where the client wants to have the server attach
the already stored key vs. the case where the client wants to create a
new key regardless whether there is one stored or not.
Does that make sense?
On 03/05/2015 01:58 PM, John Bradley wrote:
>
Right, but do we need to say that in Dyn-Reg? That's really more of a
problem for the protocol using the keys, not the one registering it for use.
-- Justin
On 3/5/2015 7:58 AM, John Bradley wrote:
I am ok with saying that the JWK must have keyed if there is more than one key
and it SHOULD i
I am ok with saying that the JWK must have keyed if there is more than one key
and it SHOULD if there is only one.
Sent from my iPhone
> On Mar 5, 2015, at 1:43 PM, Hannes Tschofenig
> wrote:
>
> Hi John,
>
> that's a good idea. However, the dynamic client registration should
> state that t
Hi Justin,
in a security specification we should be able to say exactly what the
semantic of a certain attribute is.
What I expect happening today is that many organizations provide both
resource server and authorization server and agree in an out-of-band
fashion what the meaning of that value is
Hi John,
that's a good idea. However, the dynamic client registration should
state that the "kid" parameter is used and must be included in the JWK
(since the kid is an optional parameter).
The key name is then the 'kid' plus the client id since the value of the
kid is not unique by itself.
Ciao
I'm OK with a separate registry, my only question is whether or not
there's a way to correlate and coordinate the values of the two
registries. The concern with importing the JWT claims directly into
introspection's response was that we'd potentially be stepping on an
existing namespace. In pra
The "active" claim boils down to the AS saying "Do I think this token is
any good or not?" and it's really up to the AS how it determines that.
Our own implementation does a data store lookup on the token value. If
it finds the token, then the token is active. If the token had been
revoked, or
The kid in the JWT is the most appropriate thing if the iss has reregistered a
jwks_uri. If you send a jwks_uri the AS needs to have some trust model to
match the "iss" to that jwks_uri that we haven't described for Connect or Oauth
at this point.
Mostly we have been sticking to jwks that are
For signing authentication requests you include the keyid in the JWT, and the
AS looks in the JWKS to find the correct key if there is more than one.
I don't think that is a problem
What we probably need to do is pass a keyid in the request if there is more
than one signing key registered for t
If you're using them for the token endpoint, you set your
token_endpoint_authorization_method to a method that supports it (which
we don't define in OAuth but other protocols and profiles do). Then
you'll usually reference them using the 'kid' field defined in JWK, or
you might just use the onl
Hi Justin, Hi all,
In context of the draft-ietf-oauth-pop-key-distribution-01 update we
just ran into a question regarding key naming.
The Dynamic Client Registration Protocol defines these two parameters
that allow a client to upload a public key to the authorization server:
jwks_uri
U
Hi John,
On 03/05/2015 10:27 AM, John Bradley wrote:
> inline
>> On Mar 5, 2015, at 9:59 AM, Hannes Tschofenig
>> wrote:
>>
>> Hi all,
>>
>> I refreshed the PoP key distribution document. No changes to the
>> content of the document.
>>
>> The document contains two questions, namely
>>
>> QUEST
inline
> On Mar 5, 2015, at 9:59 AM, Hannes Tschofenig
> wrote:
>
> Hi all,
>
> I refreshed the PoP key distribution document. No changes to the
> content of the document.
>
> The document contains two questions, namely
>
> QUESTION: A benefit of asymmetric cryptography is to allow clients to
Hi all,
I refreshed the PoP key distribution document. No changes to the
content of the document.
The document contains two questions, namely
QUESTION: A benefit of asymmetric cryptography is to allow clients to
request a PoP token for use with multiple resource servers. The
downside of t
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Proof-of-Possession: Authorization Server
to Client Key Distribution
Authors
Hi Mike, Hi Justin,
I guess you agree with me that fundamentally the JWT and the token
introspection solve the same problem, namely to provide the
authorization server with information that it can use to make an
authorization decision. The difference is only in the way how the
message flows.
Now,
27 matches
Mail list logo
