Two ways to handle complexity here.
Reading over the minutes, I'm not sure it was clear the main point of
observation I am trying to make to the group.
The current design assumes that every client is somehow completely different as
the majority standing. This has lead to a design where all prot
>I believe Tony commented that "if something is optional, it means that ALL
>servers everywhere have to support it". I don't understand that - the
>requirement for servers to ignore (i.e., don't throw an error or fall
over) if a client sends over a parameter it doesn't understand has always been
Thanks a lot John for your answer.
How about the server to server flow per se as in [0].
Is it standardized anywhere (OAuth/OIDC)? Or is just custom at Google?
I think this is kind of clever and really suites case where there is not "human
interaction"
regards
Antonio
__
Hmmm. We are defining token drafts that discuss key distribution. Part of my
objection is that doing a different method in reg not only overloads reg but
complicates key mgmt.
Phil
On 2013-08-23, at 9:16, John Bradley wrote:
> We have that in the OIDC version where the client publishes it's
We have that in the OIDC version where the client publishes it's public key.
That is in general better from a security point of view if you believe clients
can securely generate key pairs.
It is not in the IETF version because we were asked not to include
authentication methods not defined in
Thanks for the notes, Hannes.
I didn't speak up on the call at all because it honestly left me a bit
confused. For the first 3/4 or so I was trying to figure out what the
problem was that everyone was fighting about. Phil, Tony, and others
seemed to be pointing out that "in all of these cases that
Hi Hannes,
thanks a lot for your notes.
As suggested from you guys yesterday I'd like to bring on my little point :)
(that is really orthogonal to the whole discussion).
IMHO since the dynamic registration is still on a design phase it would be
really nice to include something that Google alre
Hi all,
while we managed to make some progress during yesterday's conference
call it was clear that we need more time.
From the information you guys entered into the poll I selected the next
suitable date, which is Wed 28 Aug, 2pm PDT. This call will be for 90min
(rather than 60min).
I wil
Thank you all for joining yesterday's conference call. I took some notes
during the call.
Meeting Minutes
Participants:
- William Kim
- John Bradley
- Antonio Sanso
- Mike Jones
- Phil Hunt
- Justin Richer
- Hannes Tschofenig
- Derek Atkins
- Amanda Anganes
- Morteza Ansari
- Brian Ca
