[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Salsa as authentication provider for Debian



On Wed, Apr 08, 2020 at 04:51:49AM +0000, Paul Wise wrote:

> Is there any documentation and diagrams on the typical request flows
> between the browser the servers involved that happens with OIDC?
> Is there an OIDC demo site somewhere so that I can see the requests
> between the browser and the servers involved and see which browser
> features OIDC uses and requires in practice?

My goal in this discussion is to see if there are blockers for moving in
the direction that me and Waldi proposed, or to discover unexpected ways
in which what we propose would make the situation worse than it is now.

I would like to keep this discussion focused on ACK/NACK, so that me and
waldi and whoever may want to join the work, can go ahead and start
putting together implementation schedule and get things moving.

Are your questions an expression of curiosity about the OIDC protocol,
or about hinting that there is something there that you consider a
blocker to be discussed before we start working?


> > However, I don't know how a moderation workflow should work.
> 
> I'd like to see this happen via a "welcome" team. You register an
> account with a paragraph about why you're signing up, your account
> gets moderated and you receive a welcome email from the team with tips
> related to your signup paragraph and to the service where you started
> the registration flow, for eg people starting their registration on
> the wiki might get a link to the wiki editor guide.
> 
> https://wiki.debian.org/Welcome

I would definitely like to see the Welcome Team take off, and I would
prefer not to derail what seems like a workable plan about improving the
broken Single Sign-On situation, into a discussion about a Debian
Welcome Team.

I'd love to have a healty, active, and pervasive Welcome Team, and maybe
Salsa's an excellent opportunity for Welcome Team contributions.

Unless you think having a functional Welcome Team onboard should be
considered a blocker for moving on with SSO improvements, could we
postpone this to a later point?


I'd like to keep this round of discussion focused on two points:

 - is the current situation broken?
 - with this proposal, does it become less broken? 

That the current situation is broken seems to be generally agreed.

I haven't yet seen anything that convinced me that what we are proposing
would make it more broken, or would prevent further opportunities for
moving on.

If no serious blockers show up, in a few days I would start to go ahead.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

Attachment: signature.asc
Description: PGP signature


Reply to: