Dan P.

Today you can't grant access to shares outside of the share owner's organization - do you have any more information on your use case that might help us as we think through future improvements to data and access control in MotherDuck? There isn't a way for users outside of your organization to view a dive within the app but you can generate embedded dive links if you have a place you want to host these. It is true that anyone with the link will be able to see the dive content and access the data referenced by the dive

Hey Will, if you shoot me a DM with your email I can help get you unblocked

Hey Aaron A.! I meant to message you earlier. The fixes I made should be in the release so I don't think you'll have the same SSO problems as before. Want to give it a try sometime tomorrow?

Sorry for not following up on the thread Yana C. - we ran into a similar issue after this so I turned off SSO for their organization and have some fixes in the works that we can hopefully get out in the next release

could you DM me your email address?

I'll take a quick look at the login issue

Hey Aaron A.! I've added the capitalized domain to our system to see if that fixes your problem - can you let me know if this unblocks you enabling SSO? If so I'll look into patching the capitalization issue more broadly

ok that makes sense -- definitely seems like a reasonable request to get some information about the org/user that is associated with a token

apologies for all the questions/brainstorming -- just trying to get an accurate picture to understand how it may or may not be supported by any future features we work on

A related question is: Do you need a hierarchical identifier to be resolvable by MotherDuck or is it just something for you to use internally to group databases that exist in the same context. If it is the latter it seems like it might work to generate your own arbitrary unique identifier that you associate with each token?