Thanks for the feedback Ken, very useful. Would be good to catch up over a coffee or something before you leave.
A few quick comments below, but will answer more substantially when I start to cut the next draft and look at your points in more detail. > Rhys, > I've done my homework (fearing Leif's steely eye) and reviewed the draft on > the UI considerations (Sept 25 version). I'll be at IETF Sunday night through > Wednesday, in case you'd like to chat further about this, but have to leave > before the ABFAB session on Thursday. > There's a lot of "still to do" sections in the draft, as you know – I'd be > glad to look at them. > A few overarching comments, and then some specifics on the draft. > 1. I'm glad that you're looking at the larger discovery problem issues > rather than just the ABFAB use case. That said, it does bring the discussion > close to other efforts such as AccountChooser. In speaking to John Bradley > recently, they have many of the concerns that you mention (most notably they > are now considering how to control what IdP's can register with an SP or an > accountchooser location – trying to get into a dynamic process such as the > one you mention, etc. Some reference to those discussions might be useful. > 2. There is almost no mention of privacy related issues. As a matter of > form, there should be such as a section. Maybe mention the issues around > hiding IdP's (we've had instances where people wanted to conceal their IdP > choices from interested governments –certainly not the US :)) - to whether an > IdP follows privacy principles (via an end-entity tag or some other > information that might want to be shown to the user.) One of the other ways > this could be brought out is via some mention of identifiers. Absolutely, given I’m one of the authors of 6973, not having a privacy section just wouldn’t be right :-). > In your terminology section, I would introduce the identifier vs identity > distinction, one I'm trying to hammer on in NSTIC. You mention that a user > MAY have multiple identities. It would be good to say that an identity MAY > have multiple identifiers associated with it, in order to preserve privacy, > etc. Good point, agree totally. > The first sentence in section 4 could use some smoothing – seems like an > awkward sentence. In that same section, you talk about a headless mode > operation, but don't define it (and I, as a semi-knowledgeable reader don't > know what it means.) OK I’ll try to sort that out. FYI, headless mode operation would be - how do you do authentication in a world without a GUI? (e.g. machine to machine authentication via ABFAB). > The first sentence in section 6 uses "firstly" - not English on this side > of the pond. And at the end of section 6.1, a typo (exmaple instead of > example). > In section 7, first sentence needs the word "tell" to be singular (tells). > Also, the many-many scenario you talk about, in terms of complexities, might > be best addressed with a single identity and a mechanisms for that identity > to convey the role its in. Maybe hard in an ABFAB case, but maybe not and > worth a mention as an alternative. > Again, willing to review new sections as they are added. A topic close to > home for me. Super. Rhys. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: [email protected] / [email protected] GPG: 0xDE2F024C
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
