Subject: [OAUTH-WG] AC4 and what does it solve?

From: Bill Mills <[email-masked]>
Date: Thu, 15 May 2014 08:51:20 -0700 (PDT)

I'm reading the AC4 draft and I want to understand the problems it's actually trying to solve, which isn't as clear as it could be in the prose.  It looks like it's extending OAuth to:

1) Allowing the client to specify a desired authentication level.
2) Giving the client an opaque identifier to differentiate users.
3) Telling the client what level of authentication was used.

Do I have this right?

Thanks,

-bill

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 15 May 2014 16:14:27 +0000

Phil,

I also just read draft-hunt-oauth-v2-user-a4c-02.
This proposal sounds awfully close to what UMA is
doing for consent management.

The Resource Owner (RO) in UMA has the option to
set access control policy (including expected the
authentication LOA of the user/client). The RO
also has the option to require the Client/User to
provide Claims regarding both entities (UMA
distinguishes between the Client and the Human
person using the Client). UMA relies on
OpenID-Connect OP to provide the Claims.

btw. is your intention to create something akin to
AuthnContext in SAML2.0?

Best.

/thomas/

____________________________________________

From: OAuth [mailto:[email-masked]] On
Behalf Of Bill Mills
Sent: Thursday, May 15, 2014 11:51 AM
To: OAuth WG
Subject: [OAUTH-WG] AC4 and what does it solve?

I'm reading the AC4 draft and I want to understand
the problems it's actually trying to solve, which
isn't as clear as it could be in the prose.  It
looks like it's extending OAuth to:

1) Allowing the client to specify a desired
authentication level.
2) Giving the client an opaque identifier to
differentiate users.
3) Telling the client what level of authentication
was used.

Do I have this right?

Thanks,

-bill

---

From: Phil Hunt <[email-masked]>
Date: Thu, 15 May 2014 09:42:55 -0700

Thomas,

The intent was to be compatible with Connect (by request) but to solve only the authentication issue.  That would explain the overlap with UMA.

The issue (or bug?) we face is that OAuth Clients who continue to use 6749 alone, aren’t really authenticating users.

More importantly there is the question that has emerged over the past year about whether the client should know and be able to request authentication techniques and or levels.  There is a demarcation issue to sort out.

There is also the re-authen requirement that happens a lot where clients wish to elevate assurance level some how and may want to access a resource (not related to user profile).  In the re-auth case, you know the users profile, you just want to confirm is this really Thomas?  Just using OpenID means a much more complicated set of requests if only because everything has to be done twice.

Regarding AuthnContext, I understand the same issue happened and the model chosen (for assurance) didn’t work. I don’t want to repeat past sins (as Brian says). I believe LoA was the solution to the problem, but I think Mike wants to talk some more about it — which is why it is in draft 02. 

Phil

@independentid
www.independentid.com
[email-masked]

On May 15, 2014, at 9:14 AM, Thomas Hardjono <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Thu, 15 May 2014 16:53:35 +0000

The "acr" claim (authentication context class reference) and the "acr_values" request parameter are explicitly modelled on the SAML authentication context work, but without the more complicated parts that didn't work out well in practice.  In this case, the request is just an ordered list of requested "acr" values.  Some of those values might be level numbers, but they also can and will be URNs such as "urn:mace:incommon:iap:silver" or "urn:mace:incommon:iap:bronze".  In fact, the same values can be used as are used with SAML, if it makes sense in the application context.

Phil, I don't understand why you're saying re-auth would be any different with full Connect than with AC4.  The re-auth request would be the same - an OAuth authorization request using prompt=none - in both cases.

				Cheers,
				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, May 15, 2014 9:43 AM
To: Thomas Hardjono
Cc: OAuth WG
Subject: Re: [OAUTH-WG] AC4 and what does it solve?

Thomas,

The issue (or bug?) we face is that OAuth Clients who continue to use 6749 alone, aren't really authenticating users.

Regarding AuthnContext, I understand the same issue happened and the model chosen (for assurance) didn't work. I don't want to repeat past sins (as Brian says). I believe LoA was the solution to the problem, but I think Mike wants to talk some more about it - which is why it is in draft 02. 

Phil

@independentid
www.independentid.com
[email-masked]

On May 15, 2014, at 9:14 AM, Thomas Hardjono <[email-masked]> wrote:

> This proposal sounds awfully close to what UMA is doing for consent 
> management.
> 
> The Resource Owner (RO) in UMA has the option to set access control 
> policy (including expected the authentication LOA of the user/client). 
> The RO also has the option to require the Client/User to provide 
> Claims regarding both entities (UMA distinguishes between the Client 
> and the Human person using the Client). UMA relies on OpenID-Connect 
> OP to provide the Claims.
> 
> btw. is your intention to create something akin to AuthnContext in 
> SAML2.0?
> 
> Best.
> 
> /thomas/
> 
> From: OAuth [mailto:[email-masked]] On Behalf Of Bill Mills
> I'm reading the AC4 draft and I want to understand the problems it's 
> actually trying to solve, which isn't as clear as it could be in the 
> prose.  It looks like it's extending OAuth to:
>

---

From: Bill Mills <[email-masked]>
Date: Thu, 15 May 2014 11:11:27 -0700 (PDT)

The "re-auth" problem is an interesting one, the question of how does the client know if the user new authentication matches the previous one for something like mailbox access?  What happens if the end user doesn't auth as the same user?  If you really need this I think Connect solves this well, and OAuth is currently ocmpletely silent on this. 

 I don't think the userID indication to the client really does what we want.  If we want to do this in OAuth I think it would be better to hand the expired token back to the AS and say "this is the user I expect" and have the AS fail if that doesn't match.

-bill
On Thursday, May 15, 2014 9:54 AM, Mike Jones <[email-masked]> wrote:

                Cheers,
                -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, May 15, 2014 9:43 AM
To: Thomas Hardjono
Cc: OAuth WG
Subject: Re: [OAUTH-WG] AC4 and what does it solve?

Thomas,

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 15 May 2014 18:28:54 +0000

Thanks Phil & Mike,

Would it possible to write this as a separate
"profile" of Connect and/or UMA?  The reason I ask
is because a somewhat standalone document could be
useful in other deployment scenarios, such as an
Enterprise use-case, where some minimal OAuth2.0
"awareness" exists.

In this case, I'm thinking specifically of a
Kerberos KDC server being able to return a
signed/encrypted Claim (JWT) that reports the LOA
value of the authentication instance (SP800-63-1
already identifies some Kerberos "levels"). The
claim could then be consumed by a Connect OP or
UMA AM/AS (without the OP or AS necessarily being
a KDC themselves), or other downstream SPs.

/thomas/

From: Bill Mills [mailto:[email-masked]] 
Sent: Thursday, May 15, 2014 2:11 PM
To: Mike Jones; Phil Hunt; Thomas Hardjono
Cc: OAuth WG
Subject: Re: [OAUTH-WG] AC4 and what does it
solve?

The "re-auth" problem is an interesting one, the
question of how does the client know if the user
new authentication matches the previous one for
something like mailbox access?  What happens if
the end user doesn't auth as the same user?  If
you really need this I think Connect solves this
well, and OAuth is currently ocmpletely silent on
this. 

 I don't think the userID indication to the client
really does what we want.  If we want to do this
in OAuth I think it would be better to hand the
expired token back to the AS and say "this is the
user I expect" and have the AS fail if that
doesn't match.

-bill

On Thursday, May 15, 2014 9:54 AM, Mike Jones
<[email-masked]> wrote:
The "acr" claim (authentication context class
reference) and the "acr_values" request parameter
are explicitly modelled on the SAML authentication
context work, but without the more complicated
parts that didn't work out well in practice.  In
this case, the request is just an ordered list of
requested "acr" values.  Some of those values
might be level numbers, but they also can and will
be URNs such as "urn:mace:incommon:iap:silver" or
"urn:mace:incommon:iap:bronze".  In fact, the same
values can be used as are used with SAML, if it
makes sense in the application context.

Phil, I don't understand why you're saying re-auth
would be any different with full Connect than with
AC4.  The re-auth request would be the same - an
OAuth authorization request using prompt=none - in
both cases.

                Cheers,
                -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On
Behalf Of Phil Hunt
Sent: Thursday, May 15, 2014 9:43 AM
To: Thomas Hardjono
Cc: OAuth WG
Subject: Re: [OAUTH-WG] AC4 and what does it
solve?

Thomas,

The intent was to be compatible with Connect (by
request) but to solve only the authentication
issue.  That would explain the overlap with UMA.

The issue (or bug?) we face is that OAuth Clients
who continue to use 6749 alone, aren't really
authenticating users.

More importantly there is the question that has
emerged over the past year about whether the
client should know and be able to request
authentication techniques and or levels.  There is
a demarcation issue to sort out.

There is also the re-authen requirement that
happens a lot where clients wish to elevate
assurance level some how and may want to access a
resource (not related to user profile).  In the
re-auth case, you know the users profile, you just
want to confirm is this really Thomas?  Just using
OpenID means a much more complicated set of
requests if only because everything has to be done
twice.

Regarding AuthnContext, I understand the same
issue happened and the model chosen (for
assurance) didn't work. I don't want to repeat
past sins (as Brian says). I believe LoA was the
solution to the problem, but I think Mike wants to
talk some more about it - which is why it is in
draft 02. 

Phil

@independentid
www.independentid.com
[email-masked]

> The Resource Owner (RO) in UMA has the option to
set access control 
Behalf Of Bill Mills
authentication level.
differentiate users.