Replaced by FedCM login-status API?
jameshartig opened this issue · 7 comments
Is https://github.com/fedidcg/login-status replacing this proposal?
Based on what I heard from @johnwilander at TPAC (notes here), yes, I do believe that https://github.com/fedidcg/login-status is a more up to date explainer for this API than what's in this repo. I don't know if we want to point this repo to that one, or merge the text and move this repo to the FedID CG. But I do believe that:
- we agreed on the text of the explainer described here and
- we agreed to move this to the FedID CG (and at some point, to the Identity Credential WG that is starting to form
@johnwilander did I get this right? i'd be happy to course correct and fix any misunderstanding or confusion I may have created.
Let’s work on getting a PR on this spec since it’s the original proposal and has a lot of community input.
Let’s work on getting a PR on this spec since it’s the original proposal and has a lot of community input.
Are you still happy with the explainer that we co-wrote at TPAC that we pasted here?
https://github.com/fedidcg/login-status
If so, I can send a PR to use this as the explainer for this repo. If not, can you send PRs with any further suggestions you may have?
@johnwilander friendly ping? how do you want us to go about this?
We recently chartered the FedID WG to include the Login Status API, so we are trying to figure out a few things:
- Do you want us to move this repo under the https://github.com/w3c-fedid org?
- Do you still like the explainer that we co-wrote last TPAC 2023?
- Do you still want to be a co-editor of the specification?
Hi! I think it should remain its own spec, I want to remain as editor or coeditor, and we have some feedback on what’s in Chrome today since it deviates from the shape of the API we proposed in an unfortunate way. Specifically sending the status as a string. We’d like to discuss it at TPAC.
Hi! I think it should remain its own spec
Great! I'm breaking this up from the FedCM spec in this PR.
, I want to remain as editor or coeditor,
Great! I'll add you as the co-editor!
we have some feedback on what’s in Chrome today since it deviates from the shape of the API we proposed in an unfortunate way. Specifically sending the status as a string. We’d like to discuss it at TPAC.
Can you expand on this a bit? We implemented what we discussed at TPAC last year here. Did chrome's implementation deviate from this?
I think it should remain its own spec, I want to remain as editor or coeditor
Ok, just to report back here, I just finished breaking the spec out of the FedCM spec and publishing this here as a co-editor: