inline below On Tue, Nov 6, 2018 at 12:53 PM Evan Gilman <evan2...@gmail.com> 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 need while keeping things simple. > Agreed. I am far from an authority here, but it is my understanding that one > of the primary drivers in supporting SAN over Subject is that the > values are strongly typed. While some of the advantages gained from > this may be less useful in our own context, I feel that it make sense > to keep the values separate and not overload a single value. I'm likewise no authority but have a similar understanding. Because the advantages of a typed name are less clear in this context is why I've been wanting to simplify with an overloaded parameter. But that's probably ultimately a bad idea. So yeah, I'm agreeing that separating the types is the way to go. Whether > that means dedicated metadata parameters or a structured parameter > value, I am not sure what the tradeoffs would be, but both options > sound suitable to me. > Seems like it's largely an esthetic thing but perhaps the benefits or drawbacks of one over the other will become more apparent as we dig into it more. Great. I will work on some sample text since it sounds like that would > be generally helpful > I think it would, yes. Thank you! -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
