
Workgroup
Developing standards for federated authentication systems that enable cross-platform identity verification while maintaining accountability and audit trails.
A peek at recent conversation in DP1 - Federated Authentication & Accountability. Join to read the full history and post.
Join workgroup →Alan Karp sent these notes on DP1 by email:
I finally got a chance to read through the chapter. I don't know that what I have to say should carry much weight. The whole book (I read the Introduction and DP1.) appears to be about governance, while my expertise is in access control.
What I read is quite well written, and I agree 100% with the goals, but I didn't see anything on mechanisms that can enforce them. The Introduction says that's intentional, but I won't be convinced until I see the next level of detail. I speak from experience; I've come up with more than one great idea that proved unworkable. That's the sense I get for several of the features, containment included.
I do have a strong objection to DP1, Federated Strong Authentication. The belief that it's needed comes from the ancient days of managing secrets in controlled environments, think the Manhattan Project. The requirement is unscalable and leads to unnecessary complications in a world of remote access. What's needed is Federated Strong Authorization. Alice decides to work with Bob and authenticates him any way she chooses. Bob decides to work with Carol doing the same. There's no need for Alice to authenticate Carol even if Bob's asked her to work on Alice's task. Alice will hold Bob responsible for Carol's use of Alice's resources. You get trust, identity, and accountability transitively instead of globally.
Daveed's reply to Alan Karp, sent by email:
Hi Alan,
Thank you for reading, and please don't discount your view. Access control is exactly where several of these properties will succeed or fail. Your point about DP1 is the kind of correction I hoped for.
I've proposed your Alice, Bob and Carol model in DP1, credited to you:
In DP1, below the sentence "Agents, tools, and collaborators may act on a participant's behalf,…", I've proposed: "Accountability can be transitive rather than global. When Alice works with Bob and Bob brings in Carol to help with Alice's task, Alice need not authenticate Carol: she authenticates Bob in whatever way she chooses and holds Bob responsible for Carol's use of her resources. Trust, identity, and accountability then flow along chains of delegated authorization, which scales to remote and open collaboration where requiring every party to authenticate every other does not."
It will show up in the chapter's discussion, and you can comment on or refine it there. It is posted under your name.
I did not rename DP1 from authentication to authorization. That is a bigger change, and the DP1 workgroup should decide it, but your proposal now puts the argument in front of them.
On mechanisms: you are right that V1 does not show them, and I take the warning seriously. When we get to the next level of detail, I would value your eyes on it.
With thanks, Daveed
Community Chats match workgroup Collab: human messages in the main panel and private Deepi in the right sidebar. Invite people outside the workgroup by email or link. This is separate from Workgroup Chat, which stays inside the member thread.
Start a Community Chat for DP1 - Federated Authentication & Accountability. You pick who joins. Everyone invited can post in the member chat and use private Deepi in the sidebar. The chat appears in your Deepi sidebar with a Community badge.
Sign in to start a Community Chat from Deepi.
Opens Deepi with the invite flow. Community Chats also appear under My conversations at /agent.