Thanks Evan.
This seems like a good start and I'll plan to work to incorporate the
proposal in some/similar form into the next revision of the document.
Comments, clarifications, etc. from the WG are also always welcome too in
the meantime. Or from the AD, who also suggested allowing for the use o
I have taken a stab at some text that will open the door for SAN-based
subject identity support. Some minor modifications in section 2.1, and
additional metadata parameters in section 2.1.2. Please find that text
below.
> I scanned through the SPIFFE docs but didn’t any mentioning of OAuth (just
Hi Evan,
I scanned through the SPIFFE docs but didn’t any mentioning of OAuth (just
plain X.509). What’s your plan for introducing OAuth and mtls?
kind regards,
Torsten.
> Am 13.11.2018 um 00:59 schrieb Evan Gilman :
>
> Thank you everyone for the feedback.
>
> I am currently working on the
Thank you everyone for the feedback.
I am currently working on the sample text, and should be complete in
the next couple days. Apologies for the delay.
On Wed, Nov 7, 2018 at 12:51 AM Brian Campbell
wrote:
>
> Sure, I think they could be treated as different different
> client_auth_methods. But
Sure, I think they could be treated as different different
client_auth_methods. But there is a lot more commonality than differences
to the point where I think it makes sense to keep it all in a single
document and under a single client auth method with just the variation on
which name is being use
inline below
On Tue, Nov 6, 2018 at 12:53 PM Evan Gilman wrote:
> There are some extra things we could do if we attached type-specific
> semantics to the matching (e.g. DNS wildcarding etc), however I think
> that continuing to use the values as opaque identifiers would get us
> most of what we
Thanks for referring us to this spec. How I read it, every way to represent an
application identity may require specific verification rules (including typ
specific syntactical rules).
In my interpretation this means we must explicitly manage expected type and
value of the identifier used to ma
Would it make sense for these to be a different client_auth_method entirely?
Much the same way that we have private_key_jwt and client_secret_jwt today,
both of which use the JWT assertion framework but have very different keying
and security assumptions. In the same way, here you’re still valid
You might want to look at RFC6125 which covers this topic and provides
recommendations for representing application in certificates:
https://tools.ietf.org/html/rfc6125
Regards,
Rifaat
On Tue, Nov 6, 2018 at 3:53 PM Evan Gilman wrote:
> Response(s) inline
>
> On Mon, Nov 5, 2018 at 11:53 PM N
Response(s) inline
On Mon, Nov 5, 2018 at 11:53 PM Neil Madden wrote:
>
> Is there an intention that any semantics are attached to the SAN being a URI
> or DNS name or IP or ...? Or is it still intended to be an opaque identifier?
There are some extra things we could do if we attached type-spec
Is there an intention that any semantics are attached to the SAN being a URI or
DNS name or IP or ...? Or is it still intended to be an opaque identifier?
> On 6 Nov 2018, at 01:55, Brian Campbell
> wrote:
>
> Thanks Evan for bringing this to the WG's attention. More or less the same
> questi
Thanks Evan for bringing this to the WG's attention. More or less the same
question/issue was raised yesterday in the area director's review of the
document as well. I plan to bring this up as a discussion item in the
meeting today. But my sense from some early discussions is that there is
likely t
Hello everyone.
Very excited to see this draft. It helps tremendously in addressing
use cases around oauth client management in machine-to-machine
scenarios. Particularly, the PKI authentication method.
In reviewing the document, I noticed that the only supported method
for identifying a client u
13 matches
Mail list logo
