I see your point that it is a fine line reporting how a person authenticated to a Authorization endpoit (it might be by SAML etc) and encouraging people to use OAuth for Authentication.
We already have the amr response in connect. The only thing really missing is a registry. Unless this is a sneaky way to get requested_amr into Connect? John B. > On Jan 20, 2016, at 5:37 PM, Justin Richer <jric...@mit.edu> wrote: > > Just reiterating my stance that this document detailing user authentication > methods has no place in the OAuth working group. > > — Justin > >> On Jan 19, 2016, at 6:48 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> >> wrote: >> >> Hi all, >> >> this is the call for adoption of Authentication Method Reference Values, see >> https://tools.ietf.org/html/draft-jones-oauth-amr-values-03 >> >> Please let us know by Feb 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >> >> Note: The feedback during the Yokohama meeting was inconclusive, namely >> 9 for / zero against / 6 persons need more information. >> >> You feedback will therefore be important to find out whether we should >> do this work in the OAuth working group. >> >> Ciao >> Hannes & Derek >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
