Hi Tony, not sure I understand your point.
Are you saying that we (the proposers of the new WG) *technically*
needn't account for feedback such as Torsten's in this review cycle?
Paul
On 7/2/13 1:03 PM, Anthony Nadalin wrote:
Since this is slated to be an OpenID WG, it's what the WG wants to do.
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of *Torsten
Lodderstedt
*Sent:* Tuesday, July 2, 2013 9:53 AM
*To:* Paul Madsen
*Cc:* John Bradley; [email protected]; [email protected]
*Subject:* Re: Native application SSO Working Group
Hi Paul,
got it :-) Would it make sense to add this assumption to the charter?
Does this mean:
- a single AZA manages access to multiple authz servers?
- an app needs to be able to register its authz server/idp at the AZA?
Thanks,
Torsten.
Paul Madsen <[email protected]
<mailto:[email protected]>> schrieb:
Hi Torsten, wrt the possibility of an id_token being used against
a 'home' IdP, the current model is that it would be the AZA that
would perform this exchange, not the native app itself - this
because the overarching assumption being that the AZA should do as
much of the heavy lifting as possible - and thereby simplify life
for the native apps.
But that is separate I think from the use case of an native app
wanting to consume an id_token directly (for access control,
customization etc) and so i will look at charter to make sure this
scenario is supported.
paul
On 7/2/13 11:31 AM, Torsten Lodderstedt wrote:
Hi,
I agree with Nat on this use case. Another one is that the app
wants to use the id_token as credential on its "home" IDP
(probably via JWT bearer token profile). This is more or less
3rd party login for apps.
regards,
Torsten.
Nat Sakimura <[email protected]> <mailto:[email protected]>
schrieb:
Yes. If the app wants the identity information to evaluate
its own access control, then it would probably want to
know about the user identity (i.e., set of attributes
related to the entity), and id_token is the right thing.
When I was talking to some law enforcement people in EU,
they were talking similar things. Right now, we do not
have any location data defined in the claims, but we may
also want to do so in such cases.
Nat
2013/7/3 Paul Madsen <[email protected]
<mailto:[email protected]>>
Hi Nat, the current AZA model does not preclude an
access token being formatted as an id_token.
I believe Torsten was conjecturing that there was
potential value in an id_token being delivered to a
native app in addition to an access token (whether
formatted as id_token or not)
Regards
paul
On 7/2/13 10:53 AM, Nat Sakimura wrote:
I actually do see some utility in the access token
in the format of ID Token.
It can give appropriate audience restriction etc.
2013/7/2 Paul Madsen <[email protected]
<mailto:[email protected]>>
Hi Torsten, the current model is that the
Authorization Agent (AZA) may itself obtain an
id_token and use it to obtain an access token,
but that only access tokens would be 'handed
over' by the AZA to its constituent native apps.
Are you proposing that there may be value in
allowing the AZA to also hand over id_tokens
(suitably targeted) as well?
paul
On 7/1/13 1:38 PM, Torsten Lodderstedt wrote:
Hi John,
I interpreted the text of the charter the
other way around, so a client would be
able to use an(y) id_token (as a
credential) to obtain an access token. I'm
fine if the mechanism is intended to
support id_token issuance.
regards,
Torsten.
Am 01.07.2013 15:06, schrieb John Bradley:
Hi Torsten,
In point 3 the charter talks about
using id_tokens to get access tokens.
So it is imagined that the mechanism
would issue id_tokens likely along the
lines that Google is doing for the
play store by having a 3rd party as an
audience and using "azp" to indicate
the client the token was issued to.
We don't want to be too specific on
the solution in the charter.
If you think something needs to be
added let me know.
John B.
On 2013-07-01, at 2:17 AM, Torsten
Lodderstedt <[email protected]
<mailto:[email protected]>> wrote:
Hi,
it would be great to have such a
mechanism across platforms!
I'm wondering whether the
mechanism should issue id tokens
as well. Right now it seems to
focus on access tokens.
Regards,
Torsten.
John Bradley <[email protected]
<mailto:[email protected]>> schrieb:
The enclosed Work Group Charter is
being sent to the Specs Council for review in anticipation of chartering the
Group.
It is best have this activity under the
foundation IPR as soon as possible.
Regards
John B.
------------------------------------------------------------------------
specs mailing list
[email protected]
<mailto:[email protected]>
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
<mailto:[email protected]>
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
<mailto:[email protected]>
http://lists.openid.net/mailman/listinfo/openid-specs
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
