Hey Greg In the past I've handed the Silverlight xap file something random (lets call it a key to get in) in the init parameters. The client then gives that back to the WCF service as proof that the Xap file was launched by a known web server. You could renew it periodically or let it run for that session and next time it runs it gets a different key. I'm sure there are other ways but this one skips the whole log in requirement. You could also use standard web authentication before they get to the Silverlight page too so the user would have to log in before getting a key/Xap.
YMMV cheers Stephen p.s. you could also give back the spec (for more clarification) and tell them its too vague, but I know that that's not always an option. On Tue, Nov 25, 2014 at 8:06 PM, Greg Keogh <g...@mira.net> wrote: > Folks, I have a Silverlight Phone app that talks to a WCF service. The > spec says that phones must *prove* to the service that they are > legitimate and trusted. I figure therefore that I will stuff something in > the message headers of each call that can't be forged to prove a phone has > legitimate client software ... but what? > > The spec is vague and does not specify any kind of "login" method or > handshake to establish trust. > > To confuse matters, I've been given a pair of X509 certificates (as cer > and pfx files) without any hint about what to do with them. So I've been > reading about X509's for hours, but I can't figure out if they're of any > help in this situation or not. All the sample code I've found using > certificates is for the full CLR and not for the Silverlight CLR where many > classes are smaller or missing. I can't figure out how to use X509s for > solving my problem (if they are of any use). > > Any suggestions from crypto protocol boffins out there? > > *Greg K* >
