Thanks for the review Erik,
We will go through it in detail and get back to you.
I am working with a couple of governments on how a eID app could use the self
issued profile of OpenID Connect to issue tokens.
There are also other out of band authentication apps that people use that need
to be
Hi,
Thanks for a great document! I volunteered to review
draft-wdenniss-oauth-native-apps-00 at the #IETF93 meeting so here we go:
In national mobile eID deployments an app is issued by gov or other
organisation in a country. The app acts as the users authentication method
and it works with an ID
I agree that an obvious good thing to do is to add spec references to the field
definitions.
I need to investigate use cases for amr_values. I think this came from
developers who actually wanted this for a particular purpose but I’ll have to
get back to the WG on that. It’s defined here, rath
So, allow me a naive question.
I supppose there are good random otp, as well as pretty bad otp etc.
Would it be useful to say just "otp". Would it not be better to have at
least a field that references a spec that specifies the security
requirement for that mechanism?
2015-07-23 12:05 GMT+02:00 Wi
Here are the notes from our meeting yesterday:
https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth
Thanks to Erik for taking notes.
Please let me know if something is missing or incorrect within the next
2 weeks.
Ciao
Hannes
signature.asc
Description: OpenPGP digital signature
__
> Now, as to the spec change is concerned, I agree with John that it is not
> required.
>
> However, a Best practice document would probably help the developers.
That's exactly what I had in mind -- no spec change, but something (or
some things) to help guide developers into do the right thing,
se
I do tend to agree John that clients shouldn't be able to force the sp on
choices.
My thought was that it was useful to have a registry so we can have standard
auth method values for protocols that get written like oidc. It may be useful
elsewhere.
Anyway as a general rule I think it is som
So maybe a naive question but why does this draft define "amr_values" while
also suggesting that it's fragile and that "acr" & "acr_values" is
preferable? Seems contradictory. And I doubt I'm the only one that will
find it confusing.
On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones
wrote:
> The key
The key part of this is establishing a registry. That can only be done in an
RFC.
John, I encourage you to submit text beefing up the arguments about why using
“acr” is preferable. The text at
http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship
is a start at tha
I don’t personally have a problem with people defining values for AMR and
creating a IANA registry.
That exists for ACR.
I am on record as not supporting clients requesting amr as it ai a bad idea and
the spec mentions that at the same time it defines a new request parameter for
it.
It is pr
Useful work, but shouldn’t this be defined in the OIDF, where the “amr"
parameter is defined?
— Justin
> On Jul 22, 2015, at 7:48 PM, Mike Jones wrote:
>
> Phil Hunt and I have posted a new draft that defines some values used with
> the “amr” (Authentication Methods References) claim and est
11 matches
Mail list logo
