I suggest that you have a look at the syntax for "CREATE LOGIN" - it has some info in SID

SID is short for security identifier (or at least that is my understanding). For windows users, Active Directory automatically assigns a SID to each and everything that it knows about. No matter what a Windows user accesses, the SID is used to identifier the user (this is a highly abridged discussion on this - you could spend hours reading up on what AD actually does when identifying and authenticating users).

SQL Server also uses a SID to identify users. For Windows users, it uses the SID that AD is already using - why create yet another identifier for the user.

For SQL Server logins, someone or something beside AD needs to supply a value for the SID (since AD has no knowledge of those logins). If you do not specify a value, the "CREATE LOGIN" command will generate one on your behalf. Normally, the value that is generated is not important but when you are using the same database on a different instance of SQL Server, it does matter. This is because SQL Server uses the SID when trying to find whether a user in a database is a login for the instance. If they don't match, then as far as SQL Server is concerned, the login does not have access to the database. If they do match, all is good.

So, when creating the login on the mirror server, by specifying the same SID as is being used on the principal server, any permissions the user has will also be present at the mirror.

And finally, the actual value of the SID is not significant - you can use the NEWID function to generate a value if you want. The only requirement is for the same value to be used on both the principal and the mirror server when creating the login.

Hope that explains SID for you