Hi Stephen, Thanks for your comments and insights on this topic, since you were an IETF Security AD for several years; In the previous email I wanted to mention a possible IETF based solution (or an enhancement of this) that can be used to support the dynamic management/refreshing of Identities, i.e., using the Federation concept proposed in RFC7831, https://www.rfc-editor.org/rfc/rfc7831.txt An enhanced ABFAB solution might be used to support the lifecycle management of Identities. The Identity provider stores the Identities and the Relying Party can be a controller that controls when the Identities need to be refreshed; These entities and their relationships are illustrated graphically below (taken from RFC7831) ,----------\ ,---------\ | Identity | Federation | Relying | | Provider + <--------------------> + Party | `----------' '---------' < \ \ Authentication \ \ \ \ \ +---------+ \ | | v| Client | | | +---------+ Entities and Their Relationships Note that the above is for further study and has not been discussed with the IDEAS proponents; Best regards, Georgios -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx] Sent: Friday, October 06, 2017 11:32 AM To: Georgios Karagiannis; Uma Chunduri; Joel M. Halpern; Benjamin Kaduk; Jari Arkko Cc: ideas@xxxxxxxx; ietf@xxxxxxxx Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas) Hiya, On 06/10/17 08:49, Georgios Karagiannis wrote: > Hi all, > > Please note that I have looked into the output of the (concluded) IETF > ABFAB WG. In order to answer many questions/concerns that have been > raised during the previous IDEAS discussions, it might be useful to > consider the results of the IETF ABFAB WG. > https://datatracker.ietf.org/wg/abfab/documents/ > > We could incorporate their concepts about identity and how identity > can be established and leveraged in a distributed way able to satisfy > trust and privacy concerns. I have no clue how GSS-API is even relevant here. abfab was a fine thing for JISC and friends to do to as a way to try broaden the benefit they got from their existing federated authentication setup, in their case involving UK universities. It is not at all clear that that would be even relevant if one wanted to build the kind of all encompassing IdPs envisaged in the ideas charter/draft. The relationships that university account holders have with their own and other academic institutions and with applications running in such environments (that being the point of abfab) don't seem to me to generalise to lower layers in any useful manner. In any case, if this proposal is only now at the point where you're starting to ponder the basic architecture then I'd conclude it's nowhere near ready to charter. (As well as being a bad idea from the privacy POV;-) WGs for such decisions can be a good plan when there's a few known architectural choices on the table, and if different sets of folks need a venue to reach consensus on which road to take - suggesting abfab at this point sounds like floundering around looking for reasons to exist tbh. (Sorry to be blunt and it may not be that, but it appears to be that to me.) S. > > Best regards, Georgios > > > -----Original Message----- From: Ideas [mailto:ideas-bounces@xxxxxxxx] > On Behalf Of Uma Chunduri Sent: > Thursday, October 05, 2017 7:05 PM To: Joel M. Halpern; Benjamin > Kaduk; Jari Arkko Cc: ideas@xxxxxxxx; ietf@xxxxxxxx Subject: Re: > [Ideas] WG Review: IDentity Enabled Networks (ideas) > > Hi Joel, > > In-line [Uma]: > > > Best Regards, -- Uma C. > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@xxxxxxxxxxxxxxx] Sent: Wednesday, October 04, 2017 9:41 PM > To: Uma Chunduri <uma.chunduri@xxxxxxxxxx>; Benjamin Kaduk > <kaduk@xxxxxxx>; Jari Arkko <jari.arkko@xxxxxxxxx> Cc: > ideas@xxxxxxxx; ietf@xxxxxxxx Subject: Re: [Ideas] WG Review: > IDentity Enabled Networks (ideas) > > You seem to be making some unstated assumptions. > > If by "Provider" in "Provider based AUTH" you mean the last hop > communications service provider, then I would fundamentally disagree > with you. [Uma]: I meant IdP and it's an orthogonal discussion if both > roles played by same entity.. > > The communication service provider has no role in creating or > authenticating identifiers. Their job is to provide locators. [Uma]: > Absolutely. > > Now, those service providers may have an authentication relationship, > based on some identifiers, in order to provide communications > services. But the identifiers for that are completely uncoupled from > and unrealted to the identifiers need for an ID / Locator system. > > Yes, if there is a provider of identifiers (not all systems even > require that), > > [Uma]: Yes, may be not all systems require that, especially if this > is a local deployment. > > then the user of the identifier needs to have an appropriate > relationship with the provider of the identifier. And that needs to be > related to the authentication needed to update the mapping system. > [Uma]: Yes. > > > But neither of those require anything other than the identifier and > suitable keying. [Uma]: If it's a local system simple keying is enough > (in the expense of key management etc) as all devices may be managed > by the same org. > > _______________________________________________ Ideas mailing list > Ideas@xxxxxxxx https://www.ietf.org/mailman/listinfo/ideas > >