Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

[William Denniss <[e-mail]>]

On Thu, Feb 18, 2016 at 11:36 AM, Mike Jones <[e-mail]>
wrote:

> Thanks, William.  I’m good with referencing the registry in Section 2.
>

Great!


> I’ll think about the registered/public/private comment.
>
>
I'm not suggesting we necessarily have to use the same
registered/public/private structure, only that some discussion of
standardized vs non-standard could be helpful for implementers (e.g. try to
pick something that is collision resistant for proprietary metadata).


> It’s fine to reference oauth-mix-up-mitigation as a draft in a finished
> RFC as long as it’s an informative and not a normative reference.
>

Ah ok, I wasn't aware of that.



> *From:* William Denniss [mailto:[e-mail]]
>
> *Sent:* Thursday, February 18, 2016 11:28 AM
> *To:* Mike Jones <[e-mail]>
> *Cc:* John Bradley <[e-mail]>; Anthony Nadalin <
> [e-mail]>; [e-mail]
>
> *Subject:* Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>
>
>
> Two review comments:
>
>
>
> 1.
>
> Can the text in "Section 2.  Authorization Server Metadata" near the end
> regarding additional metadata be expanded? I think we should reference the
> IANA registry established by this spec in that section (as this will be the
> reference point for people looking for other registered metadata), and
> possibly mention something about registered vs unregistered parameters and
> interoperability. At present if you only read that section it is a little
> vague.
>
>
>
> I like the treatment of claims in the JWT spec https://tools.ietf.org/html/rfc7519#section-4.2, splitting into 3 groups: registered, public and private. Not saying we should mirror it exactly, but as an implementer I liked how clearly it was stated in that spec.
>
>
>
> 2.
>
> Since this doc is in WG Last call, do we need to remove the reference to
> the mix-up I-D (Section 2, "issuer"), or are we expecting them to be
> finalized together?
>
>
>
>
>
> On Thu, Feb 18, 2016 at 10:42 AM, Mike Jones <[e-mail]>
> wrote:
>
> I'm fine with changing dynamic registration from being RECOMMENDED to
> OPTIONAL.  That's good actionable feedback.  Likewise, looking at again, we
> also need to change jwks_uri from REQUIRED to OPTIONAL, since not all OAuth
> deployments need keys.
>
> I expect more good, actionable feedback to also come from the WGLC as
> people carefully read the draft with fresh eyes.
>
>                                 -- Mike
>
> -----Original Message-----
> From: John Bradley [mailto:[e-mail]]
> Sent: Thursday, February 18, 2016 10:33 AM
> To: Anthony Nadalin <[e-mail]>
>
> Cc: Mike Jones <[e-mail]>; Hannes Tschofenig <
> [e-mail]>; Phil Hunt <[e-mail]>;
> [e-mail]
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>
> We are establishing a registry.  Some folks do use dynamic client
> registration.
>
> We can register it in this document or take it out and let others register
> it once the registry is established.
>
> It will be registered one way or the other.
>
> One of the reasons for starting last call is to get people to read the
> draft and comment.
> That seems to be working.
>
> If you have specific security considerations, please let us know so they
> can be addressed.   Text is always appreciated.
>
> John B.
>
> > On Feb 18, 2016, at 1:27 PM, Anthony Nadalin <[e-mail]>
> wrote:
> >
> > Not sure about that. There are things that are "recommended" like the
> dynamic registration endpoint, I don't understand why this is recommended
> as a lot of folks still don't do this. There are security considerations
> about all the information that is in the discovery that have not been
> addressed.
> >
> > -----Original Message-----
> > From: Mike Jones
> > Sent: Thursday, February 18, 2016 10:18 AM
> > To: Anthony Nadalin <[e-mail]>; Hannes Tschofenig <
> [e-mail]>; Phil Hunt <[e-mail]>; John
> Bradley <[e-mail]>
> > Cc: [e-mail]
> > Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence
> >
> > It's the OAuth-specific subset of what's already widely deployed.
> Nothing was invented - just subsetted.
> >
> > I think it's already as simple as possible unless the working group
> decides to remove even more functionality (which it can obviously do).
> >
> >                               -- Mike
> >
> > -----Original Message-----
> > From: OAuth [mailto:[e-mail]] On Behalf Of Anthony Nadalin
> > Sent: Thursday, February 18, 2016 10:13 AM
> > To: Hannes Tschofenig <[e-mail]>; Phil Hunt <
> [e-mail]>; John Bradley <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
> >
> > I also think we are way far from last call (and surprised to see last
> call issued) on this document as it is still very complex for something
> that should be very simple
> >
> > -----Original Message-----
> > From: OAuth [mailto:[e-mail]] On Behalf Of Hannes
> Tschofenig
> > Sent: Thursday, February 18, 2016 6:47 AM
> > To: Phil Hunt <[e-mail]>; John Bradley <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
> >
> >
> >
> > On 02/18/2016 03:06 PM, Phil Hunt wrote:
> >> BTW. I think we are FAR from Last Call on this topic.
> >
> > Thanks for your feedback, Phil. As you have seen I had issued a WGLC
> prior to your message based on the claim from the authors that they believe
> the document is finished.
> >
> > We will, of course, take all reviews into account and see where we are
> with the discovery spec. I, as the shepherd, will also do my review and I
> encourage many working group members to also take a look at the document
> and to provide their input.
> >
> > Ciao
> > Hannes
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>